一 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网络实践的更多相关文章

  1. 【K8S】K8S-网络模型、POD/RC/SVC YAML 语法官方文档

    K8S-网络模型.POD/RC/SVC YAML 语法官方文档 Kubernetes - Production-Grade Container Orchestration kubernetes/kub ...

  2. 036.集群网络-K8S网络模型及Linux基础网络

    一 Kubernetes网络模型概述 1.1 Kubernetes网络模型 Kubernetes网络模型设计的一个基础原则是:每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的 ...

  3. [k8s]kube-router替代kube-proxy实现svc网络和pod网络

    本文讲解了kube-router部署,无需在部署kube-proxy了. kube-router采用lvs实现svc网络,采用bgp实现pod网络. kube-router也是基于cni网络,本文是容 ...

  4. K8s 从懵圈到熟练 – 集群网络详解

    作者 | 声东 阿里云售后技术专家 导读:阿里云 K8S 集群网络目前有两种方案:一种是 flannel 方案:另外一种是基于 calico 和弹性网卡 eni 的 terway 方案.Terway ...

  5. Kubernetes 从懵圈到熟练 – 集群网络详解(转)

    阿里云K8S集群网络目前有两种方案,一种是flannel方案,另外一种是基于calico和弹性网卡eni的terway方案.Terway和flannel类似,不同的地方在于,terway支持Pod弹性 ...

  6. 灵雀云Kube-OVN:基于OVN的开源Kubernetes网络实践

    近日,灵雀云发布了基于OVN的Kubernetes网络组件Kube-OVN,并正式将其在Github上开源.Kube-OVN提供了大量目前Kubernetes不具备的网络功能,并在原有基础上进行增强. ...

  7. Hadoop配置第1节-集群网络配置

    Hadoop-集群网络配置 总体目标:完成zookeeper+Hadoop+Hbase 整合平台搭建   进度:1:集群网络属性配置2:集群免密码登陆配置3:JDK的安装4:Zookeeper的安装5 ...

  8. Ceph集群网络切换

    背景:需要对已部署好的Ceph集群切换网络,包含包含公共网络和集群网络 1 关闭所有mon节点的mon服务并修改服务器IP systemctl stop ceph-mon@storage01.serv ...

  9. docker 网络实践

    #docker 网络模式 环境 centos7. , Docker version -ce docker自带网络类型 bridge,host,none,container,overlay,macvla ...

随机推荐

  1. top100 paper

  2. Spring 插件安装

    文件下载:https://pan.baidu.com/s/1jIBOggm 网站下载:http://dist.springsource.com/release/TOOLS/update/e4.5/

  3. eclipse、myeclipse使用常用的小技巧

    1.修改类名称上的@author  *** Preference----Java----Code Style----Code Templates----->Comments----->Ty ...

  4. 接口自动化测试平台 http://120.79.232.23

    接口自动化测试平台 http://120.79.232.23 T Name Latest commit message Commit time .idea 修改自动化用例修改接口时,其他接口信息被删的 ...

  5. 查漏补缺:QObject类介绍

    QObject是Qt对象模型的中心.这个模型的核心特征就是一种用于无缝对象间通信的被叫做信号和槽的非常强大的机制,可以使用connect()把信号和槽连接起来,也可以通过disconnect()来破坏 ...

  6. 正式学习MVC 02

    1.cookie 继续讲解MVC的内置对象cookie 相对不安全 1)保存cookie public ActionResult Index() { // 设置cookie以及过期时间 Respons ...

  7. 使用QT绘制一个多边形

    目录 1. 概述 2. 实现 2.1. 代码 2.2. 解析 3. 结果 1. 概述 可以通过QT的重绘事件和鼠标事件来绘制多边形,最简单的办法就是在继承QWidget的窗体中重写paintEvent ...

  8. 前端每日实战:62# 视频演示如何用纯 CSS 创作一只蒸锅

    效果预览 按下右侧的"点击预览"按钮可以在当前页面预览,点击链接可以全屏预览. https://codepen.io/comehope/pen/YvOzNy 可交互视频 此视频是可 ...

  9. 与Nexus为Maven搭建私服

    目录 Nexus 的概述 Nexus 安装与部署 Nexus 在 Windows 上安装与使用 安装 使用 Nexus 在 Linux 上安装与使用 Nexus 的概述 引用百度百科一段话 Nexus ...

  10. 如何给女朋友讲SSM和springBoot的区别?(简单描述一下)