通过 Marathon-LB 或 Edge-LB 暴露 Kubernetes API

通过内置于 Marathon-LB 或 Edge-LB 中的现有 HAProxy 暴露 Kubernetes API

通过 Marathon-LB 或 Edge-LB 暴露 Kubernetes API

如果您在 DC/OS 集群中有现有的 Marathon-LB 实例，或者如果您使用 Edge-LB (DC/OS Enterprise)，可以通过内置于 Marathon-LB 或 Edge-LB 中的现有 HAProxy 暴露 Kubernetes API。

这些选项（如下文所述）的安全性略低于 [暴露 Kubernetes API(…/exposing-the-kubernetes-api) 页面中的选项 2，因为它们使用自签名 TLS 证书来暴露 API 端点。可以使用签名证书通过 Marathon-LB 和/或 Edge-LB 将 Kubernetes API 端点暴露，但本文档中未涵盖。这些示例旨在提供一种快速、简便的方法，通过现有的 Marathon-LB 或 Edge-LB 实例暴露集群中的 Kubernetes API 端点。

这两个示例都将生成以下类似设置：

使用 HAProxy 暴露 Kubernetes API

图 1. 使用 HAProxy 暴露 Kubernetes API

所有这些示例均假设您正在将 kubernetes 用作 Kubernetes 实例的服务名称。如果您有不同的服务名称，那么可能需要进行一些更改；如下所示。

注意： 如果您有 Marathon-LB 在给定的公用代理节点上运行，那么端口 9090、9091、80、443 和 10000-10150 在默认情况下会被 Marathon-LB 消耗；考虑公用 Kubernetes 节点布局时，请牢记这一点。

示例 1：使用现有的 Marathon-LB 实例

Marathon-LB 查看所有运行的 Marathon 应用程序，并使用应用程序定义上的元数据（标签和其他属性），来确定通过 HAProxy 暴露哪个应用程序和服务。具体地说，Marathon-LB 的给定实例将查找带有指定 HAPROXY_GROUP 标签的应用程序，并暴露符合指定 HAPROXY_GROUP的应用程序。Marathon-LB 查找的默认 HAPROXY_GROUP 标签是 external。

虽然 Marathon-LB 主要用于暴露 Marathon 应用程序，但是它也可以被诱导用于暴露虚拟应用程序的非 Marathon 端点。以下是如何实现这一目标的两个示例：

  • 一个没有任何 TLS 证书验证
  • 一个在 HAProxy 和 Kubernetes API 之间有 TLS 验证（但不是用户和 HAProxy 之间）

这两个示例均假设 Marathon-LB（版本 1.12.1 或更高版本）已正确安装和配置（遵循 Marathon-LB 安装说明）。

无 TLS 证书验证的 Marathon-LB

例如，如果您有默认的 Marathon-LB 实例，那么您可以通过以下定义来运行 Marathon 应用程序，它将暴露 Kubernetes API：

{
  "id": "/kubectl-proxy",
  "instances": 1,
  "cpus": 0.001,
  "mem": 16,
  "cmd": "tail -F /dev/null",
  "container": {
    "type": "MESOS"
  },
  "portDefinitions": [
    {
      "protocol": "tcp",
      "port": 0
    }
  ],
  "labels": {
    "HAPROXY_GROUP": "external",
    "HAPROXY_0_MODE": "http",
    "HAPROXY_0_PORT": "6443",
    "HAPROXY_0_SSL_CERT": "/etc/ssl/cert.pem",
    "HAPROXY_0_BACKEND_SERVER_OPTIONS": "  timeout connect 10s\n  timeout client 86400s\n  timeout server 86400s\n  timeout tunnel 86400s\n  server kube-apiserver apiserver.kubernetes.l4lb.thisdcos.directory:6443 ssl verify none\n"
  }
}

如果您使用的是一些服务名称，而非 kubernetes，那么 apiserver.kubernetes.l4lb.thisdcos.directory:6443 应进行修改以匹配您的服务名称。例如，如果您的 Kubernetes 服务位于 kubernetes-prod，那么用 apiserver.kubernetes-prod.l4lb.thisdcos.directory:6443 替换 apiserver.kubernetes.l4lb.thisdcos.directory:6443。

此应用程序可通过 DC/OS UI、Marathon API、或通过 dcos 命令行（假设 JSON 被保存为文件 kubectl-proxy.json）加入到 DC/OS

$ dcos marathon app add kubectl-proxy.json

以下是其工作方式的示例：

  1. Marathon-LB 确认应用程序 kubectl-proxy 拥有设置为 external的 HAPROXY_GROUP 标签（如果您正在为您的 Marathon-LB 配置使用不同的 HAPROXY_GROUP，则进行更改）。
  2. instances、cpus、mem、cmd 和 container 字段基本上创建一个占用最小空间且无运行的虚拟容器。
  3. 单个端口表示该应用程序有一个“端口”（此信息由 Marathon-LB 使用）
  4. "HAPROXY_0_MODE": "http" 向 Marathon-LB 指示此特定服务的前端和后端配置应配置为 http。
  5. "HAPROXY_0_PORT": "6443" 告知 Marathon-LB 在端口 6443 上暴露该服务（而不是随机生成的服务端口，该端口会被忽略）
  6. "HAPROXY_0_SSL_CERT": "/etc/ssl/cert.pem" 告诉 Marathon-LB 使用自签名 Marathon-LB 证书（具有 无 CN）暴露该服务
  7. 最后一个标签 HAPROXY_0_BACKEND_SERVER_OPTIONS 指示 Marathon-LB 应将流量转发至端点 apiserver.kubernetes.l4lb.thisdcos.directory:6443，而不是虚拟应用程序，而且应在无验证的情况下使用 TLS 进行连接。另外，使用大超时值，以便 kubectl logs -f 和 kubectl exec -i -t 等调用在短期内不会突然终止。

在 HAProxy 与 Kubernetes API 之间有 TLS 证书验证的 Marathon-LB

或者，如果您使用 DC/OS 企业并将 Kubernetes 配置为使用 DC/OS CA 来签署证书，那么您可以修改虚拟应用程序，使其验证 HAProxy 与 Kubernetes API 的连接（对外部客户端，仍具有无效的自签名证书）：

{
  "id": "/kubectl-proxy",
  "instances": 1,
  "cpus": 0.001,
  "mem": 16,
  "cmd": "tail -F /dev/null",
  "container": {
    "type": "MESOS"
  },
  "portDefinitions": [
    {
      "protocol": "tcp",
      "port": 0
    }
  ],
  "labels": {
    "HAPROXY_GROUP": "external",
    "HAPROXY_0_MODE": "http",
    "HAPROXY_0_PORT": "6443",
    "HAPROXY_0_SSL_CERT": "/etc/ssl/cert.pem",
    "HAPROXY_0_BACKEND_SERVER_OPTIONS": "  timeout connect 10s\n  timeout client 86400s\n  timeout server 86400s\n  timeout tunnel 86400s\n  server kube-apiserver apiserver.kubernetes.l4lb.thisdcos.directory:6443 ssl verify required ca-file /mnt/mesos/sandbox/.ssl/ca-bundle.crt\n"  
  }
}

如果您使用的是一些服务名称，而非 kubernetes，那么 apiserver.kubernetes.l4lb.thisdcos.directory:6443 应进行修改以匹配您的服务名称。例如，如果您的 Kubernetes 服务位于 kubernetes-prod，那么用 apiserver.kubernetes-prod.l4lb.thisdcos.directory:6443 替换 apiserver.kubernetes.l4lb.thisdcos.directory:6443。

同样，此应用程序可通过 DC/OS UI、Marathon API、或通过 dcos 命令行（假设 JSON 被保存为文件 kubectl-proxy.json）加入到 DC/OS

$ dcos marathon app add kubectl-proxy.json

示例 2：创建 Edge-LB 池

如果您是在 DC/OS 集群中使用 Edge-LB，而不是使用 Marathon-LB，那么您可以创建 Edge-LB 池，以将 Kubernetes API 暴露给客户端。

注意: 此示例不会验证 Kubernetes 客户端与 HAProxy 之间的证书或者 HAProxy 与 Kubernetes API 之间的证书。这些验证是可实现的，但在本文档未涵盖。

{
  "apiVersion": "V2",
  "name": "kubectl-proxy",
  "count": 1,
  "autoCertificate": true,
  "haproxy": {
    "frontends": [{
      "bindPort": 6443,
      "protocol": "HTTPS",
      "certificates": [
        "$AUTOCERT"
      ],
      "linkBackend": {
        "defaultBackend": "kubernetes-apiserver"
      }
    }],
    "backends": [{
      "name": "kubernetes-apiserver",
      "protocol": "HTTPS",
      "services": [{
        "mesos": {
          "frameworkName": "kubernetes",
          "taskNamePattern": "kube-apiserver"
        },
        "endpoint": {
          "portName": "apiserver"
        }
      }]
    }],
    "stats": {
      "bindPort": 6090
    }
  }
}

如果您使用的是一些服务名称，而非 kubernetes，那么 frameworkName 应进行修改以匹配您的服务名称。例如，如果您的 Kubernetes 服务位于 kubernetes-prod，那么用 "frameworkName": "kubernetes-prod" 替换 "frameworkName": "kubernetes"。

此示例假设 Edge-LB（版本 1.0.3 或更高版本）已正确安装和配置（遵循 Edge-LB 安装说明 )：

  1. 使用以上内容创建 kubectl-proxy-pool.json。

  2. 使用以下命令创建 Edge-LB 池：

    $ dcos edgelb create kubectl-proxy-pool.json

  3. 这将创建具有以下配置的 Edge-LB 池：

  4. 一（1）个在公用 DC/OS 代理节点上运行的 HAProxy 实例

  5. 使用 TLS 和自签名证书暴露端口 6443

  6. 将端口 6443 上的连接转发到匹配框架名称 kubernetes 的 Mesos 任务和在标记为 apiserver 的端口上匹配 regex kube-apiserver 的任务名称。

  7. 在端口 6090 上侦听 HAProxy stats 端点。请注意，默认情况下，会将此端口向外暴露；如果您不希望向外暴露，您可以在 stats block 中添加 "bindAddress":"127.0.0.1"。