【Kubernetes 系列】一文学会Kubernetes Service安全的暴露应用

现在，我们执行上面的命令，就可以暴露我们的service了，执行结果如下：

NAME ENDPOINTS AGE

my-nginx 172.17.0.3:80,172.17.0.8:80 23m

现在我们就能够从集群中任意节点上使用 curl 命令向 <CLUSTER-IP>:<PORT> 发送请求以访问 Nginx Service。

2.3、访问 Service

---

Kubernetes支持两种查找服务的主要模式: 环境变量和 DNS。这里我将只介绍环境变量的查找方式。

当 Pod 在节点上运行时，kubelet 会针对每个活跃的 Service 为 Pod 添加一组环境变量。 这就引入了一个顺序的问题。为解释这个问题，让我们先检查正在运行的 Nginx Pod 的环境变量。

我个人的环境变量是 my-nginx-cf54cdbf7-vr96x 你的可能会和我的不一样，直接在pod 中查看直接的环境变量。

接下来执行命令：

$ kubectl exec my-nginx-cf54cdbf7-vr96x – printenv | grep SERVICE

运行结果如下：

KUBERNETES_SERVICE_HOST=10.96.0.1

KUBERNETES_SERVICE_PORT=443

KUBERNETES_SERVICE_PORT_HTTPS=443

能看到环境变量中并没有你创建的 Service 相关的值。这是因为副本的创建先于 Service。 这样做的另一个缺点是，调度器可能会将所有 Pod 部署到同一台机器上，如果该机器宕机则整个 Service 都会离线。 要改正的话，我们可以先终止这 2 个 Pod，然后等待 Deployment 去重新创建它们。 这次 Service 会先于副本存在。这将实现调度器级别的 Pod 按 Service 分布（假定所有的节点都具有同样的容量），并提供正确的环境变量。

分别执行如下两行命令：

$ kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;

$ kubectl get pods -l run=my-nginx -o wide

你可能注意到，Pod 具有不同的名称，这是因为它们是被重新创建的。

现在我们再次执行Nginx Pod 环境变量命令，注意：现在你的环境变量又变了，请验证：

$ kubectl exec my-nginx-cf54cdbf7-fhghk – printenv | grep SERVICE

终于，我们在运行结果中，看到了Service 相关的值：

KUBERNETES_SERVICE_PORT_HTTPS=443

MY_NGINX_SERVICE_HOST=10.97.238.70

KUBERNETES_SERVICE_HOST=10.96.0.1

KU