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

2019/04/10 10:10
阅读数 29

一 Pod和SVC网络

1.1 实践准备及原理

Docker实现了不同的网络模式,Kubernetes也以一种不同的方式来解决这些网络模式的挑战。本完整实验深入剖析Kubernetes在网络层是如何实现及工作的。
实验节点架构:
clipboard
如上图所示,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的节点看作一个路由器,其网络架构如下:
clipboard

二 Pod和SVC实验

2.1 检查环境

[root@k8smaster02 ~]# ifconfig #node1上检查网络地址
clipboard
由上可知,有一个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
clipboard
Kubernetes为这个Pod找了一个主机172.24.8.71(k8smaster01) 来运行它。另外,这个Pod获得了一个在k8smaster01的docker0网桥上的IP地址。
[root@k8smaster01 study]# docker ps #k8smaster01上查看正在运行的容器
clipboard
第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后的网络模型类似下图:
clipboard
实际上,应用容器直接监听了这些端口,和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上。
clipboard
注意:本实验更详细的步骤参考:https://blog.csdn.net/qq_31136839/article/details/99778434

原文出处:https://www.cnblogs.com/itzgr/p/12552430.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部