rancher-2：rancher2.5.5部署的单节点kubernetes集群下的pod与容器探究

前置阅读：

rancher-1：使用rancher-2.5.5部署单节点kubernetes集群

用rancher2.5.5搭建单节点的kubernetes集群后，各个namespace与pod的作用探究，以及隐藏在下方的其他docker容器的探究，在衡量性价比的同时要尽量知其所以然。

目录：

(1).namespace探究

(2).pod探究

1.cattle-system下pod

2.fleet-system下pod

3.ingress-nginx下pod

4.kube-system下pod

(3).其他docker容器探究

(4).相关文章

(5).参考文档

(1).namespace探究

用rancher2.5.5搭建单节点的kubernetes集群后，共有如下4个namespace：

cattle-system

fleet-system

ingress-nginx

kube-system

cattle-system：

Rancher deployment 命名空间，rancher使用这个空间的组件在节点部署kubernetes节点；rancher也正是通过这个namespace里的组建来管理kubernetes集群的。如：升级 Kubernetes 版本、创建 etcd 快照和恢复 etcd 快照等。

fleet-system：

2020年4月3日，Rancher Labs 宣布推出全新开源项目 Fleet，致力于为用户提供海量 Kubernetes 集群的集中管理体验。管理对象不仅仅局限与k8s，同样包含k3s等。

ingress-nginx和kube-system就显然了：

ingress-nginx：存放负载均衡组件的namespace。

kube-system：存放k8s本身运行需要的系统级组件的namespace。

(2).pod探究

1.cattle-system下pod

共3个：

cattle-cluster-agent

cattle-node-agent

kube-api-auth

cattle-cluster-agent：

cattle-cluster-agent用于连接集群的Rancher 部署的 Kubernetes 集群的 Kubernetes API。cattle-cluster-agent通过 Deployment 的方式部署。

cattle-node-agent：

在执行集群操作时，cattle-node-agent用于和Rancher 部署的 Kubernetes 集群中的节点进行交互。集群操作的示例包括升级 Kubernetes 版本、创建 etcd 快照和恢复 etcd 快照。cattle-node-agent通过 DaemonSet 的方式部署，以确保其在每个节点上运行。当cattle-cluster-agent不可用时，cattle-node-agent 将作为备选方案连接到Rancher 部署的 Kubernetes 集群中的 Kubernetes API。

kube-api-auth：

部署 kube-api-auth 微服务是为了为已授权的集群端点提供用户身份验证功能，该功能仅对RKE 集群可用。当您使用 kubectl 访问下游集群时，集群的 Kubernetes API 服务器将使用 kube-api-auth 作为 webhook 对您进行身份验证。

2.fleet-system下pod

只有一个pod：fleet-agent

fleet最重要的目标是能够管理100万个分布于不同地理位置的集群。关键点在于需要处理的是大量小型集群，而不是一个有很多节点的大型集群。这些都是依赖于fleet-agent来实现。

fleet是一组由标准K8S API交互驱动的K8S Controller。

fleet agent不需要一直保持连接。

Fleet agent本身是另一组Kubernetes controller。

另外，要注意：etcd不能在此规模下运行。

fleet是作为Kubernetes Controller编写的。因此，将Fleet扩展到100万个集群意味着要在Kubernetes中管理数千万个对象。正如我们所了解的，etcd并没有能力管理这么大的数据量。

rancher为了绕过etcd的限制使用了kine：

https://github.com/k3s-io/kine

3.ingress-nginx下pod

这个就显然了，共两个：

default-http-backend

nginx-ingress-controller

通过ingress-nginx的工作原理来理解这两个pod的作用：

a1.ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化，a2.然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置。

a3.再写到nginx-ingress-control的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器会把生成的nginx配置写入/etc/nginx.conf文件中，

a4.然后reload一下使配置生效。以此达到域名分配置和动态更新的问题。

a5.default-http-backend的作用是：如果外界访问的域名不存在的话，则默认转发到这里。

4.kube-system下pod

这个也显然了，共5个：与用kubeadm搭建的集群还是有些区别。

calico-kube-controllers

canal

coredns（2个）

metrics-server

calico-kube-controllers：

提供网络通信支持。calico网络在传输的整个过程中始终都是根据iptables规则进行路由转发，并没有进行封包，解包的过程，这和flannel比起来效率就会快多了；因为flannel在进行路由转发的基础上进行了封包解包的操作，这样浪费了CPU的计算资源。flannel的功能比较简单，不具备复杂网络的配置能力。

canal：

cannal 网络使用flannel 作为node之间的连接网络，同时使用calico 作为 网络policy 管理器

但是我有一点不明白，flannel由于进行了封包解包的处理，效率要差，node之间的网络也用calico不可以么？记录，后边探索/交流。

从这个pod使用的image也可以看出一二。

coredns：

CoreDNS是Golang编写的一个插件式DNS服务器，是Kubernetes 1.13 后所内置的默认DNS服务器。

CoreDNS 的目标是成为 Cloud Native（云原生）环境下的 DNS 服务器和服务发现解决方案。

CoreDNS插件链。每个插件都执行DNS功能，例如Kubernetes服务发现，Prometheus指标或重写查询。

metrics-server：

Metrics server定时从Kubelet的Summary API(类似/ap1/v1/nodes/nodename/stats/summary)采集指标信息，这些聚合过的数据将存储在内存中，且以metric-api的形式暴露出去。

Metrics server复用了api-server的库来实现自己的功能，比如鉴权、版本等，为了实现将数据存放在内存中吗，去掉了默认的etcd存储，引入了内存存储（即实现Storage interface)。因为存放在内存中，因此监控数据是没有持久化的，可以通过第三方存储来拓展，这个和heapster是一致的。

(3).其他docker容器探究

我们可以看到，kubernetes中的pod个数明显远远少于docker容器的个数，那这是为什么呢，我们需要探究一下，要知其所以然，不能当盲盒使用。

kubernetes中pod的个数：11个

docker容器的个数：处于运行状态的是31个，处于非运行状态的是4个，总共是35个

接下来看看这些docker容器都是做什么用的。

一个pod可以有多个容器，一般情况下是有2个，一个是业务容器，一个是pause容器。所以，kubernetes中有11个pod，自然有对应的11个docker容器对应这11个pod。

我们以这个pod为例：nginx-ingress-controller-d7cs8

显然有两个容器，那么pause容器是做什么用的呢？

Pause容器 全称infrastucture container（又叫infra）基础容器。

Pause容器的作用

我们看下在node节点上都会起很多pause容器，和pod是一一对应的。

每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。

kubernetes中的pause容器主要为每个业务容器提供以下功能：

PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID。

网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。

IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信。

UTS命名空间：Pod中的多个容器共享一个主机名；Volumes（共享存储卷）：

Pod中的各个容器可以访问在Pod级别定义的Volumes。

35 - 11*2 =13，还有13个容器需要探究。

rancher-agent容器：

也就是主机, 是用来执行具体工作的机器，应该是每一个kubernetes节点都有一个rancher-agent容器。

rancher-server容器：

实际叫rancher，改名了。主要负责图形化管理主机容器, 并且储存用户的数据(账号, 主机信息, 应用(task)等).

13 - 2 = 11，还有11个容器需要探究。

细心的话可以发现，rancher安装的节点显然少了一些pod。

rancher安装的集群：

用kubeadm安装的集群：

rancher安装的集群缺少的5个pod：

kube-proxy

kube-scheduler

kube-apiserver

kube-controller-manager

etcd

而缺少的这5个"pod"在容器中可以找到:

docker ps | grep -i rancher | grep -E 'hyperkube|coreos-etcd'

且由于这5个"pod"并不是pod，所以并不会有对应的pause容器。

多出来的kubelet容器是rancher在部署kubernetes单节点集群是部署的，是node必需的组件。

Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命： a1.监视分配给该Node节点的pods a2挂载pod所需要的volumes

a3.下载pod的secret a4.通过docker/rkt来运行pod中的容器 a5.周期的执行pod中为容器定义的liveness探针 a6.上报pod的状态给系统的其他组件 a7.上报Node的状态

11 - 6 = 5，还有5个容器需要探究，这5个容器包括1个忽略掉的正在运行容器，和4个处于非运行状态下的容器。

是否还记得前边提到的这个pod:

canal：

cannal 网络使用flannel 作为node之间的连接网络，同时使用calico 作为 网络policy 管理器。

这是否意味着这个pod应该有3个容器？1个是pause，1个是calico容器，1个是flannel容器。我们验证一下：

确实如此。

5 - 1 = 4，至此，所有处于运行状态的容器都已经探究。只剩下最后4个处于非运行状态的容器了。

可以看到，最后这4个处于非运行状态的容器都是rancher通过rke安装kubernetes单节点集群是使用的容器，安装完成后自然会被stop。具体详情可以通过docker inspect 容器id去观察这4个容器，这里不赘述。

至此，总共35个容器全部探究完成。

(4).相关文章

1.rancher-1：使用rancher-2.5.5部署单节点kubernetes集群

(5).参考文档

1.Rancher首席架构师解读Fleet：它何以管理百万集群？

https://blog.csdn.net/RancherLabs/article/details/112603918

2.calico网络原理及与flannel对比

https://blog.csdn.net/ganpuzhong42/article/details/77853131

3.使用CoreDNS作为你的内网DNS服务器

https://www.iamle.com/archives/2679.html

4.容器监控实践—Metrics Server

https://segmentfault.com/a/1190000017875578

5.kubernetes中的Pause容器如何理解？

https://www.cnblogs.com/guigujun/p/10556508.html