Pod可能因为各种原因发生故障而死掉,Deployment等Controller会通过动态创建和销毁Pod来保障应用整体的健壮性。
Pod是脆弱的,但应用是健壮的
。
每个Pod都有自己的IP地址,当controller用新的Pod替代发生故障的Pod时,新Pod会分配到新的IP地址,那这时客户端如何找到并访问这个服务呢??-----Service
一、创建Service
Kubernetes Service从逻辑上代表一组pod,具体哪些Pod由label挑选。
Service有自己的IP,这个IP是不变的。客户端只需要访问Service的IP,
Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端不会有任何影响,因为Service没变。
# 编辑httpd_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd-deployment
spec:
selector:
matchLabels:
app: httpd # 通过标签选择被控制的pod
replicas: 3
template:
metadata:
labels:
app: httpd # 给pod打上标签,Service、Deployment 将会用这个 label 来挑选 Pod
spec:
containers:
- name: httpd
image: httpd
ports:
- containerPort: 80 # 转发到后端pod的端口号
Pod分配了各自的IP地址,但这些IP只能被Kubernetes Cluster中的容器与节点访问。
# 编辑httpd_service.yaml
apiVersion: v1
kind: Service
metadata:
name: httpd-service # 必填,service名称
spec:
selector:
app: httpd # 必填,在selector字段中指定了为哪一个标签的app进行负载均衡
ports: # 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议
- protocol: TCP
port: 8080 # service监听端口
targetPort: 80 # 转发到后端pod的端口号
httpd-service分配到一个CLUSTER-IP,可以通过该IP访问后端的httpd Pod。
除了我们创建的 httpd-svc,还有一个 Service kubernetes,Cluster 内部通过这个 Service 访问 kubernetes API Server。
kubectl describe service httpd-service
查看service与Pod的对应关系:
二、Service IP原理
Service的Cluster IP在哪里配置的?Cluster IP又是怎样与Pod IP映射的??---iptables
Service Cluster-ip是个虚拟的IP,是由kubernetes节点上iptables规则管理的。
通过
sudo iptables-save
命令打印当前节点的 iptables 规则,因输出较多,这里只截取与 httpd-service Cluster IP 10.98.165.152 相关的信息:
$ sudo iptables-save | grep '10.98.165.152'
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.98.165.152/32 -p tcp -m comment --comment "default/httpd-service cluster IP" -m tcp --dport 8080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.98.165.152/32 -p tcp -m comment --comment "default/httpd-service cluster IP" -m tcp --dport 8080 -j KUBE-SVC-EHNHZY2AA2RZYURI
这两条规则的含义:
1、若Cluster内的Pod(源地址来自10.244.0.0/16)要访问httpd-service,则允许;
2、其他源地址访问httpd-service(10.98.165.152/32),跳转到规则KUBE-SVC-EHNHZY2AA2RZYURI。
KUBE-SVC-EHNHZY2AA2RZYURI规则如下:
-A KUBE-SVC-EHNHZY2AA2RZYURI -m comment --comment "default/httpd-service" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-RWFU5RJRM7QIVQGD
-A KUBE-SVC-EHNHZY2AA2RZYURI -m comment --comment "default/httpd-service" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CX4QANADYSW4JX2E
-A KUBE-SVC-EHNHZY2AA2RZYURI -m comment --comment "default/httpd-service" -j KUBE-SEP-HGKXYQ3Y7I7MLDXP
-
1/3的概率跳转到规则KUBE-SEP-RWFU5RJRM7QIVQGD
-
1/3的概率(剩下2/3的一半)跳转到规则KUBE-SEP-CX4QANADYSW4JX2E
-
1/3的概率跳转到规则KUBE-SEP-HGKXYQ3Y7I7MLDXP。
这三个跳转的规则如下:
-A KUBE-SEP-RWFU5RJRM7QIVQGD -s 10.244.1.13/32 -m comment --comment "default/httpd-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-RWFU5RJRM7QIVQGD -p tcp -m comment --comment "default/httpd-service" -m tcp -j DNAT --to-destination 10.244.1.13:80
-A KUBE-SEP-CX4QANADYSW4JX2E -s 10.244.1.14/32 -m comment --comment "default/httpd-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-CX4QANADYSW4JX2E -p tcp -m comment --comment "default/httpd-service" -m tcp -j DNAT --to-destination 10.244.1.14:80
-A KUBE-SEP-HGKXYQ3Y7I7MLDXP -s 10.244.2.5/32 -m comment --comment "default/httpd-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-HGKXYQ3Y7I7MLDXP -p tcp -m comment --comment "default/httpd-service" -m tcp -j DNAT --to-destination 10.244.2.5:80
即将请求分别转发到后端的三个 Pod。
通过上面的分析,我们得到如下结论:
iptables 将访问 Service 的流量转发到后端 Pod,而且使用类似轮询的负载均衡策略。
Cluster的每个节点都配置了相同的iptables规则,这样就确保了Cluster都能通过Service的Cluster IP访问Service。
三、DNS访问Service
除了通过Cluster IP访问Service,kubernetes还提供更为方便的DNS访问。
kubeadm 部署时会默认安装 coredns 组件(只在master节点),
kubectl get deployment --namespace=kube-system
coredns是个DNS服务器,每当有新的Service被创建,coredns会添加该Service的DNS记录。
Cluster中的Pod可通过<Service_NAME>.<NAMESPACE_NAME>:<PORT>访问Service
。
可以用httpd-service.default:port访问httpd-service:
wget https-service.default:8080
用
nslookup
查看 httpd-service 的 DNS 的信息:
DNS服务器是httpd-service.default.svc.cluster.local,这实际上就是coredns组件,本身部署在kube-system namespace中的一个service。
httpd-service.default.svc.cluster.local是http-service的完整域名。
四、在指定命名空间部署Service
在 kube-public 中部署 Service httpd2-svc,配置如下:
# 编辑httpd2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd2-deployment
namespace: kube-public # 指定命名空间
spec:
selector: # 通过标签选择被控制的pod
matchLabels:
app: httpd2
replicas: 2
template:
metadata:
labels:
app: httpd2 # 给pod打上标签,Service、Deployment 将会用这个 label 来挑选 Pod
spec:
containers:
- name: httpd2
image: httpd
ports:
- containerPort: 80 # 转发到后端pod的端口号
--- # 多个资源可以在一个 YAML 文件中定义,用 --- 分割
apiVersion: v1
kind: Service
metadata:
name: httpd2-service
namespace: kube-public # 指定命名空间
spec:
selector:
app: httpd2
ports: # 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议
- protocol: TCP
port: 8080 # service监听端口
targetPort: 80 # 转发到后端pod的端口号
因为属于不同的 namespace, 必须使用httpd2-service.kube-public:8080才能访问。
五、外部访问Service
Kubernetes集群内部可以通过Cluster IP和DNS访问Service
,那集群外部如何访问Service??
Kubernetes 提供了多种类型的 Service,默认是 ClusterIP。
ClusterIP:Service通过Cluster内部的IP对外提供服务,只有Cluster内部的节点跟Pod可以访问。NodePort:Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过<NodeIP>:<NodePort>访问Service。LoadBalancer:Service利用cloud provider特有的load balancer对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
5.1、使用NodePort让外部访问Service
# 编辑httpd3.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd3-deployment
namespace: kube-public # 指定命名空间
spec:
selector: # 通过标签选择被控制的pod
matchLabels:
app: httpd3
replicas: 1
template:
metadata:
labels:
app: httpd3 # 给pod打上标签,Service、Deployment 将会用这个 label 来挑选 Pod
spec:
containers:
- name: httpd3
image: httpd
ports:
- containerPort: 80 # 转发到后端pod的端口号
--- # 多个资源可以在一个 YAML 文件中定义,用 --- 分割
apiVersion: v1
kind: Service
metadata:
name: httpd3-service
namespace: kube-public # 指定命名空间
spec:
type: NodePort # 添加NodePort类型的Service
selector:
app: httpd3
ports: # 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议
- protocol: TCP
port: 8080 # service监听端口
targetPort: 80 # 转发到后端pod的端口号
httpd3-service的TYPE为 NodePort,表示可通过 Cluster 每个节点自身的 IP 访问 Service。
PORT(S)为 8080:30150/TCP,8080是ClusterIp监听的端口,30150是节点上监听的端口,
Kubernetes会
从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。
测试 NodePort 是否正常工作:通过三个节点
IP + 端口都能够访问 httpd3-service
5.2、Kubernetes 是如何将 <NodeIP>:<NodePort> 映射到 Pod 的呢?
跟Cluster IP一样,也是
借助iptables。
$ sudo iptables-save | grep 'httpd3-service'
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-public/httpd3-service" -m tcp --dport 30150 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-public/httpd3-service" -m tcp --dport 30150 -j KUBE-SVC-X5MD3Z6GVRFIQV4Q
规则的含义:访问当前节点30150端口的请求会被应用规则KUBE-SVC-X5MD3Z6GVRFIQV4Q
KUBE-SVC-X5MD3Z6GVRFIQV4Q规则如下:
-A KUBE-SVC-X5MD3Z6GVRFIQV4Q -m comment --comment "kube-public/httpd3-service" -j KUBE-SEP-CA4JWI7MMTWMJLYK
KUBE-SEP-CA4JWI7MMTWMJLYK规则如下:
-A KUBE-SEP-CA4JWI7MMTWMJLYK -s 10.244.1.27/32 -m comment --comment "kube-public/httpd3-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-CA4JWI7MMTWMJLYK -p tcp -m comment --comment "kube-public/httpd3-service" -m tcp -j DNAT --to-destination 10.244.1.27:80
NodePort默认的是从 30000-32767 中随机分配一个可用的端口,但我们可以用nodePort指定某个特定的端口:
# 编辑httpd3.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd3-deployment
namespace: kube-public # 指定命名空间
spec:
selector: # 通过标签选择被控制的pod
matchLabels:
app: httpd3
replicas: 1
template:
metadata:
labels:
app: httpd3 # 给pod打上标签,Service、Deployment 将会用这个 label 来挑选 Pod
spec:
containers:
- name: httpd3
image: httpd
ports:
- containerPort: 80 # 转发到后端pod的端口号
--- # 多个资源可以在一个 YAML 文件中定义,用 --- 分割
apiVersion: v1
kind: Service
metadata:
name: httpd3-service
namespace: kube-public # 指定命名空间
spec:
type: NodePort # 添加NodePort类型的Service
selector:
app: httpd3
ports: # 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议
- protocol: TCP
port: 8080 # Service(Cluster IP)上监听端口
targetPort: 80 # 转发到后端pod的监听端口号、
nodePort: 30150 # 节点上监听的端口
最终,Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort。