使用 Service 连接到应用

    默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。 为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。

    多个开发人员或是提供容器的团队之间协调端口的分配很难做到规模化，那些难以控制的集群级别的问题，都会交由用户自己去处理。 Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。 Kubernetes 给 Pod 分配属于自己的集群私有 IP 地址，所以没必要在 Pod 或映射到的容器的端口和主机端口之间显式地创建连接。 这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。 文档的剩余部分详述如何在一个网络模型之上运行可靠的服务。

    该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。

    在集群中暴露 Pod

    我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。 创建一个 Nginx Pod，指示它具有一个容器端口的说明：

    这使得可以从集群中任何一个节点来访问它。检查节点，该 Pod 正在运行：

    1. kubectl apply -f ./run-my-nginx.yaml
    2. kubectl get pods -l run=my-nginx -o wide
    1. NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
    2. my-nginx-3800858182-jr4a2   1/1       Running   0          13s       10.244.3.4    kubernetes-minion-905m
    3. my-nginx-3800858182-kna2y   1/1       Running   0          13s       10.244.2.5    kubernetes-minion-ljyd

    检查 Pod 的 IP 地址：

    1. kubectl get pods -l run=my-nginx -o yaml | grep podIP
    2.     podIP: 10.244.3.4
    3.     podIP: 10.244.2.5

    应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。 需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。 这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。 像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。

    如果对此好奇，可以获取更多关于 如何实现网络模型 的内容。

    我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？ Pod 会终止，Deployment 将创建新的 Pod，且使用不同的 IP。这正是 Service 要解决的问题。

    Kubernetes Service 从逻辑上定义了运行在集群中的一组 Pod，这些 Pod 提供了相同的功能。 当每个 Service 创建时，会被分配一个唯一的 IP 地址（也称为 clusterIP）。 这个 IP 地址与一个 Service 的生命周期绑定在一起，当 Service 存在的时候它也不会改变。 可以配置 Pod 使它与 Service 进行通信，Pod 知道与 Service 通信将被自动地负载均衡到该 Service 中的某些 Pod 上。

    可以使用 kubectl expose 命令为 2个 Nginx 副本创建一个 Service：

    1. kubectl expose deployment/my-nginx
    1. service/my-nginx exposed

    这等价于使用 kubectl create -f 命令创建，对应如下的 yaml 文件：

    1. apiVersion: v1
    2. kind: Service
    3. metadata:
    4.   name: my-nginx
    5.   labels:
    6.     run: my-nginx
    7. spec:
    8.   ports:
    9.   - port: 80
    10.     protocol: TCP
    11.   selector:
    12.     run: my-nginx

    上述规约将创建一个 Service，对应具有标签 run: my-nginx 的 Pod，目标 TCP 端口 80， 并且在一个抽象的 Service 端口（targetPort：容器接收流量的端口；port：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。 查看 了解 Service 定义支持的字段列表。 查看你的 Service 资源:

    1. kubectl get svc my-nginx
    1. NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
    2. my-nginx   ClusterIP   10.0.162.149   <none>        80/TCP    21s

    正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 endpoints 暴露出来。 Service Selector 将持续评估，结果被 POST 到一个名称为 my-nginx 的 Endpoint 对象上。 当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。 检查该 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。

    1. kubectl describe svc my-nginx
    1. Name:                my-nginx
    2. Namespace:           default
    3. Labels:              run=my-nginx
    4. Annotations:         <none>
    5. Selector:            run=my-nginx
    6. Type:                ClusterIP
    7. IP:                  10.0.162.149
    8. Port:                <unset> 80/TCP
    9. Endpoints:           10.244.2.5:80,10.244.3.4:80
    10. Session Affinity:    None
    11. Events:              <none>
    1. kubectl get ep my-nginx
    1. NAME       ENDPOINTS                     AGE
    2. my-nginx   10.244.2.5:80,10.244.3.4:80   1m

    现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service <CLUSTER-IP>:<PORT> 。 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇， 可以进一步阅读服务代理 的内容。

    访问 Service

    Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件] .

    当 Pod 在 Node 上运行时，kubelet 会为每个活跃的 Service 添加一组环境变量。 这会有一个顺序的问题。想了解为何，检查正在运行的 Nginx Pod 的环境变量（Pod 名称将不会相同）：

    1. kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
    1. KUBERNETES_SERVICE_HOST=10.0.0.1
    2. KUBERNETES_SERVICE_PORT=443
    3. KUBERNETES_SERVICE_PORT_HTTPS=443

    注意，还没有谈及到 Service。这是因为创建副本先于 Service。 这样做的另一个缺点是，调度器可能在同一个机器上放置所有 Pod，如果该机器宕机则所有的 Service 都会挂掉。 正确的做法是，我们杀掉 2 个 Pod，等待 Deployment 去创建它们。 这次 Service 会 先于 副本存在。这将实现调度器级别的 Service，能够使 Pod 分散创建（假定所有的 Node 都具有同样的容量），以及正确的环境变量：

    1. kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
    3. kubectl get pods -l run=my-nginx -o wide
    1. NAME                        READY     STATUS    RESTARTS   AGE     IP            NODE
    2. my-nginx-3800858182-e9ihh   1/1       Running   0          5s      10.244.2.7    kubernetes-minion-ljyd
    3. my-nginx-3800858182-j4rm4   1/1       Running   0          5s      10.244.3.8    kubernetes-minion-905m

    可能注意到，Pod 具有不同的名称，因为它们被杀掉后并被重新创建。

    1. KUBERNETES_SERVICE_PORT=443
    2. MY_NGINX_SERVICE_HOST=10.0.162.149
    3. KUBERNETES_SERVICE_HOST=10.0.0.1
    4. MY_NGINX_SERVICE_PORT=80
    5. KUBERNETES_SERVICE_PORT_HTTPS=443

    DNS

    Kubernetes 提供了一个 DNS 插件 Service，它使用 skydns 自动为其它 Service 指派 DNS 名字。 如果它在集群中处于运行状态，可以通过如下命令来检查：

    1. kubectl get services kube-dns --namespace=kube-system
    1. NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
    2. kube-dns   ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   8m

    如果没有在运行，可以启用它。 本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx）， 一个为该 IP 指派名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（应用名为 kube-dns）， 所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname()）。 如果 CoreDNS 没有在运行，你可以参照 或者 安装 CoreDNS 来启用它。 让我们运行另一个 curl 应用来进行测试：

    1. kubectl run curl --image=radial/busyboxplus:curl -i --tty
    1. Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
    2. Hit enter for command prompt

    然后，按回车并执行命令 nslookup my-nginx：

    1. [ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
    2. Server:    10.0.0.10
    3. Address 1: 10.0.0.10
    5. Name:      my-nginx
    6. Address 1: 10.0.162.149

    到现在为止，我们只在集群内部访问了 Nginx server。在将 Service 暴露到 Internet 之前，我们希望确保通信信道是安全的。对于这可能需要：

    • https 自签名证书（除非已经有了一个识别身份的证书）
    • 使用证书配置的 Nginx server
    • 使证书可以访问 Pod 的

    可以从 Nginx https 示例 获取所有上述内容，简明示例如下：

    1. make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
    2. kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
      1. NAME                  TYPE                                  DATA      AGE
      2. default-token-il9rc   kubernetes.io/service-account-token   1         1d
      3. nginxsecret           kubernetes.io/tls                     2         1m
      1. kubectl create configmap nginxconfigmap --from-file=default.conf
      1. configmap/nginxconfigmap created
      1. kubectl get configmaps
      1. NAME             DATA   AGE
      2. nginxconfigmap   1      114s

      以下是您在运行make时遇到问题时要遵循的手动步骤（例如，在Windows上）：

      1. # Create a public private key pair
      2. openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
      3. # Convert the keys to base64 encoding
      4. cat /d/tmp/nginx.crt | base64
      5. cat /d/tmp/nginx.key | base64

      使用前面命令的输出来创建yaml文件，如下所示。 base64编码的值应全部放在一行上。

      1. apiVersion: "v1"
      2. kind: "Secret"
      3. metadata:
      4.   name: "nginxsecret"
      5.   namespace: "default"
      6.  type: kubernetes.io/tls  
      7. data:
      8.   tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
      9.   tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"

      现在使用文件创建 secrets：

      1. NAME                  TYPE                                  DATA      AGE
      2. default-token-il9rc   kubernetes.io/service-account-token   1         1d
      3. nginxsecret           kubernetes.io/tls                     2         1m

      现在修改 Nginx 副本，启动一个使用在秘钥中的证书的 https 服务器和 Servcie，都暴露端口（80 和 443）：

      使用 Service 连接到应用 - 图1

      1. apiVersion: v1
      2. kind: Service
      3. metadata:
      4.   name: my-nginx
      5.   labels:
      6.     run: my-nginx
      7. spec:
      8.   type: NodePort
      9.   ports:
      10.   - port: 8080
      11.     targetPort: 80
      12.     protocol: TCP
      13.     name: http
      14.   - port: 443
      15.     protocol: TCP
      16.     name: https
      17.   selector:
      18.     run: my-nginx
      19. ---
      20. apiVersion: apps/v1
      21. kind: Deployment
      22. metadata:
      23.   name: my-nginx
      24. spec:
      25.   selector:
      26.     matchLabels:
      27.       run: my-nginx
      28.   replicas: 1
      29.   template:
      30.     metadata:
      31.       labels:
      32.         run: my-nginx
      33.     spec:
      34.       volumes:
      35.       - name: secret-volume
      36.         secret:
      37.           secretName: nginxsecret
      38.       - name: configmap-volume
      39.         configMap:
      40.           name: nginxconfigmap
      41.       containers:
      42.       - name: nginxhttps
      43.         image: bprashanth/nginxhttps:1.0
      44.         ports:
      45.         - containerPort: 443
      46.         - containerPort: 80
      47.         volumeMounts:
      48.         - mountPath: /etc/nginx/ssl
      49.           name: secret-volume
      50.         - mountPath: /etc/nginx/conf.d
      51.           name: configmap-volume

      关于 nginx-secure-app manifest 值得注意的点如下：

      • 它在相同的文件中包含了 Deployment 和 Service 的规格
      • Nginx 服务器 处理 80 端口上的 http 流量，以及 443 端口上的 https 流量，Nginx Service 暴露了这两个端口。
      • 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。
      1. kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml

      这时可以从任何节点访问到 Nginx server。

      1.     podIP: 10.244.3.5
      2. node $ curl -k https://10.244.3.5
      3. ...
      4. <h1>Welcome to nginx!</h1>

      注意最后一步我们是如何提供 -k 参数执行 curl命令的，这是因为在证书生成时， 我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。 让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）：

      1. apiVersion: apps/v1
      2. kind: Deployment
      3. metadata:
      4.   name: curl-deployment
      5. spec:
      6.   selector:
      7.     matchLabels:
      8.       app: curlpod
      9.   replicas: 1
      10.   template:
      11.     metadata:
      12.       labels:
      13.         app: curlpod
      14.     spec:
      15.       volumes:
      16.       - name: secret-volume
      17.         secret:
      18.           secretName: nginxsecret
      19.       containers:
      20.       - name: curlpod
      21.         command:
      22.         - sh
      23.         - -c
      24.         - while true; do sleep 1; done
      25.         image: radial/busyboxplus:curl
      26.         volumeMounts:
      27.         - mountPath: /etc/nginx/ssl
      28.           name: secret-volume
      1. kubectl apply -f ./curlpod.yaml
      2. kubectl get pods -l app=curlpod
      1. NAME                               READY     STATUS    RESTARTS   AGE
      2. curl-deployment-1515033274-1410r   1/1       Running   0          1m
      1. kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
      2. ...
      3. <title>Welcome to nginx!</title>
      4. ...

      暴露 Service

      对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。 在上一段创建的 Service 使用了 NodePort，因此 Nginx https 副本已经就绪， 如果使用一个公网 IP，能够处理 Internet 上的流量。

      1. kubectl get svc my-nginx -o yaml | grep nodePort -C 5
      1.   uid: 07191fb3-f61a-11e5-8ae5-42010af00002
      2. spec:
      3.   clusterIP: 10.0.162.149
      4.   ports:
      5.   - name: http
      6.     nodePort: 31704
      7.     port: 8080
      8.     protocol: TCP
      9.     targetPort: 80
      10.   - name: https
      11.     nodePort: 32453
      12.     port: 443
      13.     protocol: TCP
      14.     targetPort: 443
      15.   selector:
      16.     run: my-nginx
      1. kubectl get nodes -o yaml | grep ExternalIP -C 1
      1.     - address: 104.197.41.11
      2.       type: ExternalIP
      3.     allocatable:
      4. --
      5.     - address: 23.251.152.56
      6.       type: ExternalIP
      7.     allocatable:
      8. ...
      9. $ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
      11. ...
      12. <h1>Welcome to nginx!</h1>

      让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 my-nginx Service 的 Type 由 NodePort 改成 LoadBalancer。

      1. kubectl edit svc my-nginx
      2. kubectl get svc my-nginx
      1. NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
      2. my-nginx   LoadBalancer   10.0.162.149   xx.xxx.xxx.xxx     8080:30163/TCP        21s
      1. curl https://<EXTERNAL-IP> -k
      2. ...
      3. <title>Welcome to nginx!</title>

      在 EXTERNAL-IP 列指定的 IP 地址是在公网上可用的。CLUSTER-IP 只在集群/私有云网络中可用。

      注意，在 AWS 上类型 LoadBalancer 创建一个 ELB，它使用主机名（比较长），而不是 IP。 它太长以至于不能适配标准 kubectl get svc 的输出，事实上需要通过执行 kubectl describe service my-nginx 命令来查看它。 可以看到类似如下内容：

      1. kubectl describe service my-nginx