K8s: 集群内Pod通信机制之环境变量
2.3 调整顺序,这时候已经有 service 了,删除 development, 重新启动 development。2.1 这里我们先反过来,先创建 deployment 再创建 service。2.2 再创建 service:svc-my-nginx.yaml。好现在服务已经运行起来了, 现在进入pod容器中。借用之前的 development 先运行起来。创建 svc-my-nginx.ya
·
集群内Pod通信机制之环境变量
- Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS
1 ) 环境变量概述
- 在Service里面通过label selector选择器去匹配到对应的pod
- 然后把流量导给对应的pod进行这个service的一个服务提供
- 也就是说你只要访问service的IP地址,就能获取后端pod提供的内容
- 不用关心Pod到底在哪?它的ip是什么?,所以可以理解为它是一个固定的虚拟地址
- 现在,我们更关心集群内部怎么进行通信的
- 在集群内部,前端怎么访问这个后端,比如说我前端的APP要访问后端的微服务的这个容器
- 写了service的地址之后,是怎么跟后端的service进行通信的
- 也就是底层的实现环节,怎么找到它的地址
- k8s 其实上涉及到服务发现的这个模式,就说我这个Service定义好了之后
- 其他服务的Pod怎么知道这个service已经好了,然后去知道它的IP地址
- 举一个例子
- 一个名称为 “my-nginx” 的 Service 暴露了 TCP 端口 80
- 同时给它分配了 Cluster IP 地址 10.1.180.155,这个 Service 生成了如下环境变量:
MY_NGINX_PORT_80_TCP_PORT=80 MY_NGINX_PORT_80_TCP_PROTO=tcp MY_NGINX_PORT_80_TCP_ADDR=10.1.180.155
- 在环境变量这种模式里面,nginx会通过这种service环境变量注入的方式注入到pod容器里面
- 这样的话容器在访问其他service的时候,就是通过service的名称
- 它有一个规则的转化,然后访问对应的一个地址,上面只是一个说明下面进行实践
2 )环境变量实践
- 注意:基于环境变量时,service要比pod要先创建,才能把这个环境变量写容器里面去
2.1 这里我们先反过来,先创建 deployment 再创建 service
-
借用之前的 development 先运行起来
apiVersion: apps/v1 kind: Deployment metadata: name: my-dep-nginx # 这个是 Deployment 对象的名称 spec: selector: matchLabels: # 匹配标签 run: my-dep-nginx # 运行匹配的 my-nginx 容器 replicas: 2 # 2个副本,会创建 2个 pod template: # 定义模板 metadata: labels: run: my-dep-nginx spec: # 模板说明 containers: - name: my-dep-nginx image: nginx resources: limits: memory: "32Mi" cpu: "100m" ports: - containerPort: 80
-
$
kubectl apply -f dep-my-nginx.yaml
创建poddeployment.apps/my-dep-nginx created
-
$
kubectl get po -w | grep my-dep
查看pod运行状态my-dep-nginx-7776c5d85c-gfzxd 1/1 Running 0 37s my-dep-nginx-7776c5d85c-w8bqq 1/1 Running 0 37s
2.2 再创建 service:svc-my-nginx.yaml
-
创建 svc-my-nginx.yaml
apiVersion: v1 kind: Service metadata: name: my-svc-nginx labels: run: my-dep-nginx spec: ports: - port: 80 protocol: TCP selector: run: my-dep-nginx
-
$
kubectl get svc
查看服务NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.1.0.1 <none> 443/TCP 4d1h my-svc-nginx ClusterIP 10.1.237.190 <none> 80/TCP 23m
-
好现在服务已经运行起来了, 现在进入pod容器中
-
$
kubectl exec -it my-dep-nginx-7776c5d85c-w8bqq -- sh
-
$
printenv | grep MY_SVC
- 现在看到,先创建 development 的 pod集群是看不到服务相关的环境变量的
- 也就是没有注入成功
2.3 调整顺序,这时候已经有 service 了,删除 development, 重新启动 development
- $
kubectl delete -f dep-my-nginx.yaml
先删除 developmentdeployment.apps "my-dep-nginx" deleted
- $
kubectl apply -f dep-my-nginx.yaml
在已有Service的情况下,重建 developmentdeployment.apps/my-dep-nginx created
- $
kubectl get po -w | grep my-dep
等待容器启动完成my-dep-nginx-7776c5d85c-fx9pt 1/1 Running 0 115s my-dep-nginx-7776c5d85c-hktm2 1/1 Running 0 115s
- $
kubectl exec -it my-dep-nginx-7776c5d85c-fx9pt -- sh
进入其中之一 - $
printenv | grep MY_SVC
MY_SVC_NGINX_SERVICE_HOST=10.1.237.190 MY_SVC_NGINX_SERVICE_PORT=80 MY_SVC_NGINX_PORT=tcp://10.1.237.190:80 MY_SVC_NGINX_PORT_80_TCP_ADDR=10.1.237.190 MY_SVC_NGINX_PORT_80_TCP_PORT=80 MY_SVC_NGINX_PORT_80_TCP_PROTO=tcp MY_SVC_NGINX_PORT_80_TCP=tcp://10.1.237.190:80
- 现在已经注入成功了
更多推荐
已为社区贡献32条内容
所有评论(0)