一、通过 Service 访问 Pod:

 
我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod
 
来保证应用整体的健壮性。换句话说,Pod 是脆弱的,但应用是健壮的。
 
每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址。这样就产生了一个问题:
如果一组 Pod 对外提供服务(比如 HTTP),它们的 IP 很有可能发生变化,那么客户端如何找到并访问这个服务呢?
Kubernetes 给出的解决方案是 Service。
 
 

创建 Service

Kubernetes Service 从逻辑上代表了一组 Pod,具体是哪些 Pod 则是由 label 来挑选Service 有自己 IP,而且这个 IP 是不变的。客户端只需要访问 Service 的 IP,Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化,对客户端不会有任何影响,因为 Service 没有变。
 
来看个例子,创建下面的这个 Deployment:
 
  kubectl run httpd-app --image=reg.yunwei.edu/learn/httpd:latest replicaset=3
[root@cicd yml]# kubectl get pod -o wide
NAME                                READY     STATUS             RESTARTS   AGE       IP              NODE
httpd-deployment-67b8d86468-9bz57   1/1       Running            1          21h       172.20.104.9    192.168.253.11
httpd-deployment-67b8d86468-skw2n   1/1       Running            0          21h       172.20.135.28   192.168.253.10
httpd-deployment-67b8d86468-zmr75   1/1       Running            1          21h       172.20.104.7    192.168.253.11

 

我们启动了两个 Pod,运行 httpd 镜像,label 是 run: http,Service 将会用这个 label 来挑选 Pod。
Pod 分配了各自的 IP,这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问,而不能被客户端访问。
[root@node1 network-scripts]# curl  172.20.104.9:80
<html><body><h1>It works!</h1></body></html>
 
接下来创建 Service,其配置文件如下:
 

 

① v1 是 Service 的 apiVersion。
② 指明当前资源的类型为 Service
③ Service 的名字为 httpd-svc。
④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。
⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议。
 
 
执行 kubectl apply 创建 Service httpd-svc。
 
[root@cicd yml]# kubectl apply -f httpd-svc.yml 
service "httpd-svc" configured
[root@cicd yml]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
httpd-svc    ClusterIP   10.68.236.154   <none>        8080/TCP   21h
kubernetes   ClusterIP   10.68.0.1       <none>        443/TCP    22h

 

httpd-svc 分配到一个 CLUSTER-IP 10.68.236.154(service ip)。可以通过该 IP 访问后端的 httpd Pod
根据前面的端口映射,这里要使用 8080 端口。另外,除了我们创建的 httpd-svc,还有一个 Service kubernetes,Cluster 内部通过这个 Service 访问 kubernetes API Server。
 
 

 

 
也可以通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。
 
kubectl describe service httpd-svc
kubectl get pod -o wide
[root@cicd yml]# kubectl get pod -o wide
NAME                                READY     STATUS    RESTARTS   AGE       IP              NODE
httpd-deployment-67b8d86468-9bz57   1/1       Running   1          21h       172.20.104.9    192.168.253.11
httpd-deployment-67b8d86468-skw2n   1/1       Running   0          21h       172.20.135.28   192.168.253.10
httpd-deployment-67b8d86468-zmr75   1/1       Running   1          21h       172.20.104.7    192.168.253.11

 

 可以看到svc服务端点将三个pod的ip地址都包含在内了,因此才可以通过访问service的ip九能访问到集群的后端节点。

 我们在其他节点上尝试访问service:

[root@node1 network-scripts]# curl 10.68.236.154:8080
<html><body><h1>It works!</h1></body></html>

 

Endpoints 罗列了两个 Pod 的 IP 和端口。我们知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?
答案是 iptables
 

 

二、Service IP 原理:

 

Service Cluster IP 是一个虚拟 IP,是由 Kubernetes 节点上的 iptables 规则管理的。
-A KUBE-SERVICES -d 10.68.236.154/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP
 
这条规则的含义是:
如果 Cluster 内的 Pod要访问 httpd-svc,跳转到规则 KUBE-SVC-RL3JAE4GN7VOGDGP
KUBE-SVC-RL3JAE4GN7VOGDGP 规则如下:
[root@node2 /]# iptables-save   | grep KUBE-SVC-RL3JAE4GN7VOGDGP-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-INLCIAMUGTXA7N36
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-R64ZBQQHUU433KVL
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -j KUBE-SEP-PV62YIJXJGRFPHFZ

 

  1. 1/2的概率跳转到规则 KUBE-SEP-PV62YIJXJGRFPHFZ
  2. 1/2 的概率(剩下 2/3 的一半)跳转到规则KUBE-SEP-R64ZBQQHUU433KVL
上面两个跳转的规则如下:
[root@node2 /]# iptables-save   | grep  KUBE-SEP-PV62YIJXJGRFPHFZ
:KUBE-SEP-PV62YIJXJGRFPHFZ - [0:0]
-A KUBE-SEP-PV62YIJXJGRFPHFZ -s 172.20.135.28/32 -m comment --comment "default/httpd-svc:" -j KUBE-MARK-MASQ
-A KUBE-SEP-PV62YIJXJGRFPHFZ -p tcp -m comment --comment "default/httpd-svc:" -m tcp -j DNAT --to-destination 172.20.135.28:80
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -j KUBE-SEP-PV62YIJXJGRFPHFZ

 

即将请求分别转发到后端的两个 Pod。通过上面的分析,我们得到如下结论:
iptables 将访问 Service 的流量转发到后端 Pod,而且使用类似轮询的负载均衡策略
另外需要补充一点:Cluster 的每一个节点都配置了相同的 iptables 规则,这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。
iptables规则相当于路标,给我们指引但不会直接给出目的地。
 

 

 
 

二、DNS 访问 Service

 

在 Cluster 中,除了可以通过 Cluster IP 访问 Service,Kubernetes 还提供了更为方便的 DNS 访问。
DNS组件
kubeadm 部署时会默认安装 kube-dns 组件。
 
coredns 是一个 DNS 服务器。每当有新的 Service 被创建,coredns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。
比如可以用 httpd-svc.default 访问 Service httpd-svc。
kubectl run busybox --rm -ti --image=reg.yunwei.edu/learn/busybox:latest /bin/sh
wget httpd-svc:8080
 
 

三、外网访问 Service:

 
外网如何访问 Service?
除了 Cluster 内部可以访问 Service,很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service,默认是 ClusterIP。
ClusterIP 
Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP。
NodePort 
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过 <NodeIP>:<NodePort> 访问 Service。
 

LoadBalancer 

Service 利用 cloud provider 特有的 load balancer 对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
 
下面我们来实践 NodePort,Service httpd-svc 的配置文件修改如下:

 

添加 type: NodePort,重新创建 httpd-svc。查看service状态
  kubectl apply -f httpd-svc.yml
 
[root@cicd yml]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
httpd-svc    NodePort    10.68.236.154   <none>        8080:26055/TCP   22h
kubernetes   ClusterIP   10.68.0.1       <none>        443/TCP          23h
 
  Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP,不同的是:
  1. EXTERNAL-IP 为 none,表示可通过 Cluster 每个节点自身的 IP 访问 Service。
  2. PORT(S) 为 8080:26055。8080 是 ClusterIP 监听的端口,26055 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。
 
 
下面测试 NodePort 是否正常工作。
 
通过两个节点 IP + 26055端口都能够访问 httpd-svc。
NodePort 默认是的随机选择,不过我们可以用 nodePort 指定某个特定端口。
 
现在配置文件中就有三个 Port 了:
 
nodePort 是节点上监听的端口。(意思是在其他节点上访问 三个node节点ip:nodepoint
[root@cicd yml]# curl 192.168.253.14:26055
<html><body><h1>It works!</h1></body></html>
 
 
port 是 ClusterIP 上监听的端口。
[root@node1 network-scripts]# curl 10.68.236.154:8080      #8080为service的ip的端口
<html><body><h1>It works!</h1></body></html>
 
 
targetPort 是 Pod 监听的端口。
[root@node2 /]# curl 172.20.104.9:80        #pod端口也就是运行在node节点上的pod群
<html><body><h1>It works!</h1></body></html>

 
 
 
posted on 2019-06-21 18:19  猪肉佬!  阅读(998)  评论(0编辑  收藏  举报