暴露 Kubernetes API

DC/OS Kubernetes 不会自动在 DC/OS 集群外部暴露 Kubernetes API。因此，要从 DC/OS 集群外部访问 Kubernetes API，您必须设置可以到达 DC/OS VIP（在 DC/OS 集群内暴露 Kubernetes API）的代理。

此 VIP 为 apiserver. <SERVICE_NAME>.l4lb.thisdcos.directory:6443，其中， <SERVICE_NAME> 是安装包时您所提供的服务名称。默认为 <SERVICE_NAME> is kubernetes，所以，默认情况下， VIP 是 apiserver.kubernetes.l4lb.thisdcos.directory:6443。

在接下来的部分中，我们将介绍您可以遵循的两个示例，以便将 Kubernetes API 暴露于 DC/OS 集群之外。第一个示例提供了快速尝试 DC/OS Kubernetes 的方式，而无需担心建立信任。第二个示例是对第一个示例的扩展，以便建立完全安全的设置。

另外，如果您在 DC/OS 集群中运行 Marathon-LB 和/或 Edge-LB，您可以通过其中的一个暴露 Kubernetes API。有关操作的详细信息记录于此处。

为了让用户成功遵循示例，其 DC/OS 集群必须至少有一个共用代理（例如，网络上一个代理，允许从集群外部 ingress）。在示例中，<ip-of-public-agent> 代表 IP 地址，通过该地址可以找到此公用代理。用户必须也可以从其工作站通过 SSH 来访问此 DC/OS 公用代理。最终，用户将得到以下类似设置：

使用 HAProxy 暴露 Kubernetes API

图 1. 使用 HAProxy 暴露 Kubernetes API

示例 1：使用 HAProxy 和自签名证书

警告

本示例旨在提供一种快速、简单的方式来将 Kubernetes API 暴露于 DC/OS 集群（即开即用）外部。对于暴露 Kubernetes API 的问题，这不是一个完全安全的解决方案，不得用于生产。

此示例侧重于在 DC/OS 集群外暴露 Kubernetes API，将 HAProxy 作为中间代理，并使用自签名通配符证书，已确保用户和 HAProxy 之间的通信。

步骤 1：创建自签名通配符证书

要保持 HAProxy 与用户之间的连接，必须获得 TLS 证书和私钥。因为此示例仅适用于在没有任何其他安全问题的情况下暴露 Kubernetes API，自签名通配符证书会被生成和使用。为了实现此目的，用户可以使用 openssl：

# openssl genrsa 2048 > haproxy-key.pem
# openssl req -new -x509 -nodes -sha1 -days 3650 -key haproxy-key.pem \
    -subj "/C=US/ST=CA/L=SF/O=Mesosphere/OU=dcos-kubernetes/CN=*" > haproxy-crt.pem
# cat haproxy-crt.pem haproxy-key.pem > haproxy.pem

运行这些命令将在用户的当前目录中创建 haproxy.pem 文件，随后会用到该文件。

步骤 2：创建 HAProxy 配置

您现在可以运行以下命令（根据需要替换 <SERVICE_NAME> 占位符），以创建有效的 HAProxy 配置：

# cat <<EOF > haproxy.conf
global
    log 127.0.0.1 local0
    # Sets the maximum size of the Diffie-Hellman parameters used for generating
    # the ephemeral/temporary Diffie-Hellman key in case of DHE key exchange.
    tune.ssl.default-dh-param 2048
    # Enables debug mode which dumps to stdout all exchanges.
    # This should be disabled in production, as tokens will also be logged.
    debug

defaults
    log global
    mode http
    option httplog
    option dontlognull
    # Set appropriate values for timeouts. This is important so that calls such
    # as "kubectl exec" or "kubectl logs -f" do not exit prematurely due to
    # inactivity in the connection.
    timeout connect 10s
    timeout client 86400s
    timeout server 86400s
    timeout tunnel 86400s

frontend frontend_all
    bind :6443 ssl crt /haproxy/haproxy.pem
    mode http
    default_backend backend_kube_apiserver

backend backend_kube_apiserver
    mode http
    balance leastconn
    server kube-apiserver apiserver.<SERVICE_NAME>.l4lb.thisdcos.directory:6443 check ssl verify none
EOF

运行此命令将在当前的目录中创建 haproxy.conf 文件随后会用到该文件。

步骤 3：将证书和 HAProxy 配置复制到公用代理

HAProxy 将从 DC/OS 公用代理文件系统的目录中读取其配置以及所需的 TLS 材料。这可以是任何目录，只要 HAProxy 进程可以稍后访问（在以下步骤中 <path-to-haproxy-config-directory>表示为 ）。要通过 SSH 将所需的 TLS 材料复制到 DC/OS 公用代理，您可以运行以下命令（根据需要替换占位符）：

# ssh <user>@<ip-of-public-agent> \
    mkdir <path-to-haproxy-config-directory>
# scp haproxy.pem \
    haproxy.conf \
    <user>@<ip-of-public-agent>:<path-to-haproxy-config-directory>
haproxy.pem     100%    2985    16.9KB/s    00:00
haproxy.conf    100%    1041     5.9KB/s    00:00

步骤 4：运行 HAProxy

在此步骤中，HAProxy 被配置为在 DC/OS 公用代理上运行的 Marathon 应用程序。要实现此目的，可以使用以下命令（根据需要替换 <path-to-haproxy-config-directory>）：

# cat <<EOF > marathon.json
{
  "id": "/kubernetes-haproxy",
  "acceptedResourceRoles": [
    "slave_public"
  ],
  "cmd": "/usr/local/sbin/haproxy -f /haproxy/haproxy.conf",
  "constraints": [
    [
      "hostname",
      "UNIQUE"
    ]
  ],
  "container": {
    "type": "MESOS",
    "volumes": [
      {
        "containerPath": "/haproxy",
        "hostPath": "<path-to-haproxy-config-directory>",
        "mode": "RO"
      }
    ],
    "docker": {
      "image": "haproxy:1.7",
      "forcePullImage": false,
      "parameters": []
    }
  },
  "cpus": 0.1,
  "instances": 1,
  "mem": 128,
  "networks": [
    {
      "mode": "host"
    }
  ],
  "portDefinitions": [
    {
      "protocol": "tcp",
      "port": 6443
    }
  ],
  "requirePorts": true
}
EOF

# dcos marathon app add marathon.json

部署 HAProxy 后，您应该能够看到以下内容：

# dcos task
NAME                HOST        USER    STATE  ID                                                       MESOS ID                                 REGION    ZONE
(...)
kubernetes-haproxy  10.138.0.7  root    R      kubernetes-haproxy.beaca041-5e7c-11e8-8c11-ce5fc4b24b83  cc965893-270f-4809-9617-e190904dae27-S0  us-west1  us-west1-b

现在可以访问 Kubernetes API：

# curl -k https://<ip-of-public-agent>:6443
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {

  },
  "code": 403
}

要配置 kubectl，以使用此设置访问 Kubernetes API，您现在应遵循连接客户端页面中“无 TSL 验证”小节所述的步骤。

示例 2：使用 HAProxy 并建立信任

实例 1 中提供的解决方案有几个缺点：

Kubernetes API 向 HAProxy 提供的证书未经验证。
HAProxy 向用户提供的证书太宽泛（而且也未验证）。
此外，它还假设 Kubernetes API 将在 DC/OS 公用代理的 IP 地址上被访问。
它假设 HAProxy 会将所有传入流量路由至 Kubernetes API VIP。

在生产场景中，您可能想要解决所有这些缺点，以提高解决方案的整体安全性，并且能够使用相同的 HAProxy 实例暴露多个服务/ 端点。此示例基于前一个示例，侧重于解决所有这些缺点。

步骤 1：验证 Kubernetes API 证书

要完全保持 HAProxy 与 Kubernetes API 之间的连接，必须告知 HAProxy 如何信任由 Kubernetes API 提供的 TSL 证书。这可以通过告诉 HAProxy 签署 TLS 证书的签署单位值得信赖来完成。为了实现此目的，您必须联系 TLS 证书签署单位：

# dcos task exec kube-apiserver-0-instance cat ca-crt.pem > dcos-kubernetes-ca.pem

运行此命令将在当前的目录中创建 dcos-kubernetes-ca.pem 文件，该文件现在必须复制到 <path-to-haproxy-config-directory>DC/OS 公用代理中的 目录。您还必须根据以下示例更新 HAProxy 配置，并将更新的配置复制到 DC/OS 公用代理：

backend backend_kube_apiserver
    (...)
    server kube-apiserver apiserver.<SERVICE_NAME>.l4lb.thisdcos.directory:6443 check ssl verify required ca-file /haproxy/dcos-kubernetes-ca.pem

步骤 2：验证 HAProxy 证书

在实例 1 中，自签名、通配符证书被使用。在生产场景中，您需要使用由知名、可信任的证书签署单位签署的有效证书。您可能还想使用一个域名（例如，kube-apiserver.example.com），而不是 IP 地址，来访问 Kubernetes API。为了完成此步骤，您必须确保：

您拥有对于 kube-apiserver.example.com 域有效的证书（和匹配的私钥）；
位于 example.com 的 DNS 以此方式配置，以便 kube-apiserver.example.com 解析为 DC/OS 代理（HAProxy 在运行）的 IP 地址；
您选择拥有证书签署单位（签署过上述证书）签发的证书（以防还未被操作系统信任）；

如何解决这三项，高度依赖于您的设置。在本示例的其余部分中，假设这些项已解决。

当您拥有证书和私钥（针对将被使用的域）后（在这种情况下，kube-apiserver.example.com），您必须把在实例 1 中创建的 haproxy.pem 文件替换为同时包含新证书和私钥（按特定顺序）的新文件，并将该文件通过 SSH 复制到 DC/OS 代理。您还必须将包含证书签署单位证书的文件作为 ca.pem 通过 SSH 复制到 DC/OS 代理。最后，您必须根据以下示例更新 HAProxy 配置：

frontend frontend_all
    # /haproxy/haproxy.pem contains the certificate and key for kube-apiserver.example.com
    # /haproxy/ca.pem contains the certificate(s) of the certificate authority that signed
    # haproxy.pem. This is only required if the CA is not already trusted by the operating
    # system.
    bind :6443 ssl crt /haproxy/haproxy.pem ca-file /haproxy/ca.pem
    (...)

此时，您应遵循“有 TLS”中所述的步骤连接客户端页面中“无 TSL 验证”小节所述的步骤。

步骤 3：使用 HAProxy 服务多个服务/端点

如上所述，用户可能希望使用正在部署的相同 HAproxy 实例来暴露其他服务或端点。为了实现这一目的，您可以使用服务器名称指示。然后，接收请求，HAProxy 将根据所请求的域名决定使用哪个后端。

要将请求转发至 kube-apiserver.example.com，然后再转发至一直使用的 Kubernetes API VIP，您必须根据以下示例来更新 HAProxy 配置：

frontend frontend_all
    (...)
    # Inspect the SNI field from incoming TLS connections so we can forward to
    # the appropriate backend based on the server name.
    use_backend backend_kube_apiserver if { ssl_fc_sni kube-apiserver.example.com }

可根据需要为其他域设置额外的转发规则。举个更多信息，请参阅 HAProxy 文档。

暴露 Kubernetes API

设置代理以暴露 Kubernetes API