本章看点:

  1. 理清Deployment,ReplicaSet和Pod的关系,以及三者之间的网络关系,ip地址和端口号
  2. 通过Pod进入docker容器修改里面的内容
  3. 外部网络访问Pod里面的应用

一、通过 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:

# 创建
[root@kube-node1 tmp]# kubectl run test-nginx --image=nginx --replicas=3 # 查看deployment
# kubectl get deployment -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
test-nginx 3/3 3 3 103m test-nginx nginx run=test-nginx # 查看replicaset
# kubectl get replicaset -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
test-nginx-5f44949cd4 3 3 3 102m test-nginx nginx pod-template-hash=5f44949cd4,run=test-nginx # 查看pod
[root@kube-node1 tmp]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-nginx-5f44949cd4-f55pm 1/1 Running 0 103m 172.30.112.6 kube-node1 <none> <none>
test-nginx-5f44949cd4-sdgxd 1/1 Running 0 103m 172.30.48.4 kube-node2 <none> <none>
test-nginx-5f44949cd4-zxqsc 1/1 Running 0 103m 172.30.32.7 kube-node3 <none> <none> # 注意查看pod的名称 流程如下:
用户通过kubectl创建Deployment
Deployment创建ReplicaSet
ReplicaSet创建Pod 对象的命名方式是:子对象的名字=父对象名字+随机字符串或数字

我们启动了三个 Pod,运行 nginx镜像,label 是 run: test-nginx,Service 将会用这个 label 来挑选 Pod。

Pod 分配了各自的 IP,这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问,而不能被客户端访问。

# 查看pod的label
# 第一种方法
[root@kube-node1 tmp]# kubectl get replicaset -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
test-nginx-5f44949cd4 3 3 3 102m test-nginx nginx pod-template-hash=5f44949cd4,run=test-nginx # 如下是第二种方法
[root@kube-node1 tmp]# kubectl describe pod test-nginx-5f44949cd4-f55pm
Labels: pod-template-hash=5f44949cd4
run=test-nginx # 修改三个pod里nignx的首页信息
# 这三个pod就是docker启动的三个容器,使用进入容器的方法进行修改,使用下面的命令获得容器相关信息
[root@kube-node1 tmp]#docker ps | grep "test-nginx"
62c6ba6410d9 nginx "nginx -g 'daemon of…" 2 hours ago Up 2 hours k8s_test-nginx_test-nginx-5f44949cd4-zxqsc_default_cf77a798-0437-11ea-8ea0-000c291d1820_0 # 然后进入该容器进行首页内容修改
[root@kube-node1 tmp]# docker exec -it 62c6ba6410d9 /bin/bash
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# echo "192.168.75.112" > /usr/share/nginx/html/index.html
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# cat index.html
192.168.75.110
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# exit # 因为这三个pod分布在三个node节点上,所以另外两个pod也按照这个方法进行修改

接下来创建 Service,其配置文件如下:

apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
# type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
# nodePort: 26055
selector:
run: test-nginx

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service

③ Service 的名字为 nginx-svc。

④ selector 指明挑选那些 label 为 run: test-nginx的 Pod 作为 Service 的后端。

⑤ 将 Service 的 80 端口映射到 Pod 的 80 端口,使用 TCP 协议。

执行 kubectl apply 创建 Service hnginx-svc。

[root@kube-node1 tmp]# kubectl apply -f nginx-svc.yml
service "nginx-svc" configured [root@kube-node1 tmp]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc ClusterIP 10.254.148.192 <none> 80/TCP 11s

nginx-svc 分配到一个 CLUSTER-IP 10.254.148.192(service ip)。可以通过该 IP 访问后端的 nginx Pod

根据前面的端口映射,这里要使用 80 端口。另外,除了创建的nginx-svc,还有一个 Service kubernetes,Cluster 内部通过这个 Service 访问 kubernetes API Server。

也可以通过 kubectl describe 可以查看 nginx-svc与 Pod 的对应关系。

[root@kube-node1 tmp]# kubectl describe service nginx-svc
Name: nginx-svc
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"nginx-svc","namespace":"default"},"spec":{"ports":[{"port":80,"pr...
Selector: run=test-nginx
Type: ClusterIP
IP: 10.254.148.192
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 172.30.112.6:80,172.30.32.7:80,172.30.48.4:80
Session Affinity: None
Events: <none>

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

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

# 可以看到是轮询的方式进行访问响应的
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.112
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.110
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.111

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](http://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 外部可以通过 : 访问 Service。

LoadBalancer

Service 利用 cloud provider 特有的 load balancer 对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面我们来实践 NodePort,Service nginx-svc 的配置文件修改如下:

apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
nodePort: 26055
selector:
run: test-nginx

添加 type: NodePort,重新创建 nginx-svc。查看service状态

  

[root@kube-node1 tmp]# kubectl apply -f httpd-svc.yml
[root@kube-node1 tmp]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc NodePort 10.254.148.192 <none> 80:30001/TCP 27m

Kubernetes 依然会为 nginx-svc 分配一个 ClusterIP,不同的是:

  1. EXTERNAL-IP 为 none,表示可通过 Cluster 每个节点自身的 IP 访问 Service。
  2. PORT(S) 为 80:30001。80 是 ClusterIP 监听的端口,30001则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工作。

通过三个节点 IP + 30001端口都能够访问 nginx-svc。

NodePort 默认是的随机选择,不过我们可以用 nodePort 指定某个特定端口。

现在配置文件中就有三个 Port 了:

nodePort 是节点上监听的端口。(意思是在其他节点上访问 三个node节点ip:nodepoint

# 外放用户访问
λ curl 192.168.75.110:30001
192.168.75.111 λ curl 192.168.75.111:30001
192.168.75.111 λ curl 192.168.75.112:30001
192.168.75.111

port 是 ClusterIP 上监听的端口。

[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.110
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.111
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.112
[root@kube-node3 ~]# curl 10.254.148.192:80

targetPort 是 Pod 监听的端口。

#pod端口也就是运行在node节点上的pod群
[root@kube-node1 tmp]# curl 172.30.112.6:80
192.168.75.110
[root@kube-node1 tmp]# curl 172.30.32.7:80
192.168.75.112
[root@kube-node1 tmp]# curl 172.30.48.4:80
192.168.75.111

如何访问Pod的更多相关文章

  1. 第六章 通过Service访问Pod(中)

    6.2 Cluster IP 底层实现 Cluster IP 是一个虚拟IP,是由K8s节点上的iptables规则管理的. 使用类似轮询的方法访问Pod. 6.3 DNS 访问Service 在Cl ...

  2. 第六章 通过Service访问Pod(上)

    不应该直接使用Pod的ID地址作为对外提供服务的接口,应为一旦Pod重启,IP地址就变化了,解决方案是使用Service. 6.1 创建Service K8s service从逻辑上代表了一组Pod, ...

  3. k8s如何访问pod

    1. 通过 Service 访问 Pod 我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉.Deployment 等 control ...

  4. 如何访问pod(6)

    一.通过 Service 访问 Pod: 我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉.Deployment 等 control ...

  5. kubernetes如何访问pod服务

    一.通过 Service 访问 Pod: 我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉.Deployment 等 control ...

  6. linux运维、架构之路-K8s通过Service访问Pod

    一.通过Service访问Pod 每个Pod都有自己的IP地址,当Controller用新的Pod替换发生故障的Pod时,新Pod会分配到新的IP地址,例如:有一组Pod对外提供HTTP服务,它们的I ...

  7. 第6篇如何访问pod

        一.通过 Service 访问 Pod: 我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉.Deployment 等 con ...

  8. 如何访问pod --- service(7)

    一.通过service访问pod 我们不应该期望 Kubernetes Pod 是健壮的,而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉.Deployment 等 controller ...

  9. k8s通过Service访问Pod

    如何创建服务 1.创建Deployment #启动三个pod,运行httpd镜像,label是run:mcw-httpd,Seveice将会根据这个label挑选PodapiVersion: apps ...

随机推荐

  1. Generating a Random Sample from discrete probability distribution

    If is a discrete random variable taking on values , then we can write . Implementation of this formu ...

  2. 【cf补题记录】A. Hotelier

    思考之后再看题解,是与别人灵魂之间的沟通与碰撞 A. Hotelier 题意 给出长度为n的字符串,字符串由'L'.'R'以及数字0~9组成.旅馆有10间房子,L代表客人从左边入住,R代表客人从右边入 ...

  3. 【DataStage】使用Sequence Job报错:CopyOfseq_ld..JobControl (fatal error from @Coordinator): Sequence job (restartable) will abort due to previous unrecoverable errors

    错误描述: 在使用Sequence Job加载作业的时候,报了个错,详细错误内容如下: 出现这个错误的原因是由于以下配置问题,Excution action的状态为Run造成. 解决方案: 将Excu ...

  4. rabbitmq生产者queue接收不到消息

    项目问题: 客户的UAT环境下,项目运行一段时间后,rabbitmq的生产者queue再也接收不到系统发送的消息了.因为queue接收不到消息,所以消费者无法消费数据,流程断掉了. 原因: 客户UAT ...

  5. automapper 源中有多个属性类映射到同一个 目标中

    CreateMap<TempBranchActivity, BranchActivityOutput>() .ConstructUsing((src, ctx) => ctx.Map ...

  6. layui如何隐藏弹出层关闭的按钮

    layui默认弹出层是带有关闭按钮的,但是在某些场景我们不需要layui的关闭按钮,这时只需添加closeBtn :0即可 效果图如下: 示例代码如下: layui.use('layer', func ...

  7. Java自己实现HTTP服务器来理解GET和POST区别

    GET请求和POST请求有什么区别?GET请求的参数在URL的问号后面显示,而POST参数不在URL上:POST可以比GET请求更大的数据…一般的回答都是这样.   但是作为一个高端大气上档次的程序员 ...

  8. how does SELECT TOP works when no order by is specified?

    how does SELECT TOP works when no order by is specified? There is no guarantee which two rows you ge ...

  9. java如何实现批量删除pdf指定的页数

    依赖: <dependency> <groupId>org.apache.pdfbox</groupId> <artifactId>pdfbox-app ...

  10. EMQ 与 mqtt 与 IOT设备

    1.IOT设备的特性 IOT(物联网things of internet)设备和传统的智能设备有什么区别,笔者总结下的IOT设备有如下特点: 硬件能力差(存储能力基本只有几MB,CPU频率低连使用HT ...