039.集群网络Pod和SVC网络实践

编程

一 Pod和SVC网络

1.1 实践准备及原理

Docker实现了不同的网络模式,Kubernetes也以一种不同的方式来解决这些网络模式的挑战。本完整实验深入剖析Kubernetes在网络层是如何实现及工作的。

实验节点架构:

如上图所示,Kubernetes的网络模型要求每个Node上的容器都可以相互访问。默认的Docker网络模型提供了一个IP地址段是172.17.0.0/16的docker0网桥。每个容器都会在这个子网内获得IP地址,并且将docker0网桥的IP地址(172.17.42.1)作为其默认网关。需要注意的是,Docker宿主机外面的网络不需要知道任何关于这个172.17.0.0/16的信息或者知道如何连接到其内部,因为Docker的宿主机针对容器发出的数据,在物理网卡地址后面都做了IP伪装MASQUERADE(隐含NAT)。也就是说,在网络上看到的任何容器数据流都来源于那台Docker节点的物理IP地址。这里所说的网络都指连接这些主机的物理网络。

默认的Docker网络模型简单便捷,但需要依赖端口映射的机制。在Kubernetes的网络模型中,每台主机上的docker0网桥都是可以被路由到的。也就是说,在部署了一个Pod时,在同一个集群内,各主机都可以访问其他主机上的Pod IP,并不需要在主机上做端口映射。

因此,可以在网络层将Kubernetes的节点看作一个路由器,其网络架构如下:

二 Pod和SVC实验

2.1 检查环境

[root@k8smaster02 ~]# ifconfig #node1上检查网络地址

由上可知,有一个docker0网桥和一个本地eth0地址的网络端口。

2.2 创建RC

[root@k8smaster01 study]# vi frontend-controller.yaml

  1 apiVersion: v1

2 kind: ReplicationController

3 metadata:

4 name: frontend

5 labels:

6 name: frontend

7 spec:

8 replicas: 1

9 selector:

10 name: frontend

11 template:

12 metadata:

13 labels:

14 name: frontend

15 spec:

16 containers:

17 - name: php-redis

18 image: kubeguide/guestbook-php-frontend

19 env:

20 - name: GET_HOSTS_FROM

21 value: env

22 ports:

23 - containerPort: 80

24 hostPort: 80

[root@k8smaster01 study]# kubectl create -f frontend-controller.yaml

2.3 再次检查网络

[root@k8smaster01 study]# kubectl get pods -o wide

Kubernetes为这个Pod找了一个主机172.24.8.71(k8smaster01) 来运行它。另外,这个Pod获得了一个在k8smaster01的docker0网桥上的IP地址。

[root@k8smaster01 study]# docker ps #k8smaster01上查看正在运行的容器

第2个运行的是一个google_containers/pause:latest的镜像,而且这个容器已经做了端口映射。

[root@k8smaster01 study]# docker inspect c6578085541b | grep NetworkMode #查看容器的网络模型

"NetworkMode": "default",

[root@k8smaster01 study]# docker inspect da8251102c93 | grep NetworkMode

"NetworkMode": "container:c6578085541b6f47ab624134d0ed0be352b30b42379493a71a8fc913d829989c",

解释:第1个容器是运行了“google_containers/pause:latest”镜像的容器,它使用了Docker默认的网络模型bridge(默认网络模型即为桥接);

第2个容器,也就是在RC/Pod中定义运行的php-redis容器,使用了非默认的网络配置和映射容器的模型,指定了映射目标容器为“google_containers/pause:latest”。

2.4 网络模型释义

首先,一个Pod内的所有容器都需要共用同一个IP地址,这就意味着一定要使用网络的容器映射模式。然而,为什么不能只启动第1个Pod中的容器,而将第2个Pod中的容器关联到第1个容器呢?

Kubernetes主要基于如下两个觉得考虑:

首先,如果在Pod内有多个容器的话,则可能很难连接这些容器;

其次,后面的容器还要依赖第1个被关联的容器,如果第2个容器关联到第1个容器,且第1个容器异常的话,第2个容器也将异常。

启动一个基础容器,然后将Pod内的所有容器都连接到基础容器相对容易。因为只需要为基础的这个Google_containers/pause容器执行端口映射规则,这也简化了端口映射的过程。所以启动Pod后的网络模型类似下图:

实际上,应用容器直接监听了这些端口,和google_containers/pause容器共享了同一个网络堆栈。这就是为什么在Pod内部实际容器的端口映射都显示到google_containers/pause容器上了。

[root@k8smaster01 study]# docker port c6578085541b #通过dockerport命令来检验端口转发

80/tcp -> 0.0.0.0:80

综上所述,google_containers/pause容器实际上只是负责接管这个Pod的Endpoint。

2.5 发布SVC

Service允许我们在多个Pod之间抽象一些服务,而且服务可以通过提供在同一个Service的多个Pod之间的负载均衡机制来支持水平扩展。

[root@k8smaster01 study]# vi frontend-service.yaml

  1 apiVersion: v1

2 kind: Service

3 metadata:

4 name: frontend

5 labels:

6 name: frontend

7 spec:

8 ports:

9 - port: 80

10 selector:

11 name: frontend

[root@k8smaster01 study]# kubectl create -f frontend-service.yaml

[root@k8smaster01 study]# kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

frontend ClusterIP 10.254.176.53 <none> 80/TCP 45s

释义:如上可知Kubernetes集群已经为这个服务分配了一个虚拟IP地址10.254.176.53,这个IP地址是在Kubernetes的Portal Network中分配的。 而这个Portal Network的地址范围是我们在Kubmaster上启动API服务进程时,使用--service-cluster-ip-range=xx命令行参数指定:

[root@k8smaster01 study]# cat /etc/systemd/system/kube-apiserver.service | grep 10.254

--service-cluster-ip-range=10.254.0.0/16

注意:这个IP段可以是任何段,只要不和docker0或者物理网络的子网冲突即可。选择任意其他网段的原因是这个网段将不会在物理网络和docker0网络上进行路由。这个Portal Network针对每一个Node都有局部的特殊性,实际上它存在的意义是让容器的流量都指向默认网关(也就是docker0网桥)。

2.6 确认验证

当所有的Pod都运行起来,Service将会把客户端请求负载分发到包含“name=frontend”标签的所有Pod上。

注意:本实验更详细的步骤参考:https://blog.csdn.net/qq_31136839/article/details/99778434

以上是 039.集群网络Pod和SVC网络实践 的全部内容, 来源链接: utcz.com/z/514677.html

回到顶部