关于kubernetes:Kubernetes-之-Pod-实现原理

Pod 就是最小并且最简略的 Kubernetes 对象

Pod、Service、Volume 和 Namespace 是 Kubernetes 集群中四大根本对象，它们可能示意零碎中部署的利用、工作负载、网络和磁盘资源，独特定义了集群的状态。Kubernetes 中很多其余的资源其实只对这些根本的对象进行了组合。

• Pod -> 集群中的根本单元

• Service -> 解决如何拜访 Pod 外面服务的问题

• Volume -> 集群中的存储卷

• Namespace -> 命名空间为集群提供虚构的隔离作用

Kubernetes 有许许多多的技术概念，同时对应很多 API 对象，其中最重要的也是最根底的是 Pod 对象。Pod 是在 Kubernetes 集群中运行部署利用或服务的最小单元，它是能够反对多容器的。Pod 的设计理念是反对多个容器在一个 Pod 中共享网络地址和文件系统，能够通过过程间通信和文件共享这种简略高效的形式组合实现服务。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  containers:
  restartPolicy: Always
    - name: busybox
      image: busybox
      command:
        - sleep
        - "3600"
      imagePullPolicy: IfNotPresent

Pod 的内部结构

Pod 代表着集群中运行的过程：共享网络、共享存储

在同一个 Pod 中，有几个概念特地值得关注，首先就是容器，在 Pod 中其实能够同时运行一个或者多个容器，这些容器可能共享网络、存储以及 CPU/ 内存等资源。

首先，咱们须要晓得的是，每个 Pod 都有一个非凡的被称为“根容器”的 Pause 容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分，通过 Pause 容器使工作在对应 Pod 的容器之间能够共享网络、共享存储。

Pod 共享资源

为什么 Kubernetes 会设计出一个全新的 Pod 概念，并且有这样非凡的构造？次要是因为，应用 Pause 容器作为 Pod 根容器，以它的状态代表整个容器组的状态；其次，Pod 里的多个业务容器共享 Pause 容器的 IP 地址，共享 Pause 容器挂接的 Volume 资源。

• 共享存储资源

能够为一个 Pod 指定多个共享的 Volume 资源。Pod 中的所有容器都能够访问共享的 volume 资源。Volume 也能够用来长久化 Pod 中的存储资源，以防容器重启后文件失落。

• 共享网络资源

每个 Pod 都会被调配一个惟一的 IP 地址。Pod 中的所有容器共享网络空间，包含 IP 地址和端口。Pod 外部的容器能够应用 localhost 相互通信。Pod 中的容器与外界通信时，必须调配共享网络资源，例如应用宿主机的端口映射。

veth 设施的特点

一个设施收到协定栈的数据发送申请后，会将数据发送到另一个设施下来

• veth 和其它的网络设备都一样，一端连贯的是内核协定栈

• veth 设施是成对呈现的，另一端两个设施彼此相连

# 物理网卡 eth0 配置的 IP 为 192.168.1.11
# 而 veth0 和 veth1 的 IP 别离是 192.168.2.11 和 192.168.2.10
+----------------------------------------------------------------+
|                                                                |
|       +------------------------------------------------+       |
|       |             Newwork Protocol Stack             |       |
|       +------------------------------------------------+       |
|              ↑               ↑               ↑                 |
|..............|...............|...............|.................|
|              ↓               ↓               ↓                 |
|        +----------+    +-----------+   +-----------+           |
|        |   eth0   |    |   veth0   |   |   veth1   |           |
|        +----------+    +-----------+   +-----------+           |
|192.168.1.11  ↑               ↑               ↑                 |
|              |               +---------------+                 |
|              |         192.168.2.11     192.168.2.10           |
+--------------|-------------------------------------------------+
               ↓
         Physical Network

Pod 的网络通信

集群网络解决方案: Kubernetes + Flannel

Kubernetes 的网络模型假设了所有 Pod 都在一个间接连通的扁平的网络空间中，这在 GCE(Google Compute Engine)外面是现成的网络模型，Kubernetes 假设这个网络曾经存在了。而在公有云搭建 Kubernetes 集群，就不能假设这个网络曾经存在了。咱们须要本人实现这个网络假如，将不同节点上的 Docker 容器之间的相互拜访先买通，而后能力失常运行 Kubernetes 集群。

• 同一个 Pod 内多个容器之前通过回环网络 (lo – 127.0.0.1) 进行通信

• 各 Pod 之间的通信，则是通过 Overlay Network 网络进行通信

• 而 Pod 与 Service 之间的通信，则是各节点的 iptables 或 lvs 规定

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络布局服务，简略来说，它的性能就是让集群中的不同节点主机创立的 Docker 容器都具备全集群惟一的虚构 IP 地址。而且它还能在这些 IP 地址之间建设一个笼罩的网络(Overlay Network)，通过这个笼罩网络，将数据包一成不变地传递给指标容器内。

不同状况下的网络通信形式

• 同一个 Pod 外部通信：

• 同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协定栈。

• 不同 Pod 之间通信：

• Pod1 和 Pod2 在同一台 Node 主机，由 docker0 网桥间接转发申请到 Pod2 下面，- 不通过 Flannel 的转发。

• Pod1 和 Pod2 不在同一台 Node 主机，Pod 的地址是与 docker0 在同一个网段的，但 docker0 网络与宿主机网卡是两个齐全不同的 IP 网段，并且不同的 Node 之间的通信只能通过宿主机的物理网卡进行。将 Pod 的 IP 地址和所在 Node 的 IP 地址关联起来，通过这个关联让 Pod 能够相互拜访。

• Pod 至 Service 的网络

• 目前基于性能思考，全副为 iptables 或 lvs 保护和转发。

• Pod 到外网

• Pod 想外网发送申请，查找路由表，转发数据包到宿主机的网卡，宿主机网卡实现路由抉择之后，iptables 或 lvs 执行 Masquerade，把源 IP 地址更改为宿主机的网卡的 IP 地址，而后向外网服务器发送申请。

• 外网拜访 Pod

• 通过 Service 服务来向内部提供 Pod 服务。

ETCD 之于 Flannel 提供阐明：

• 存储管理 Flannel 可调配的 IP 地址段资源

• 监控 ETCD 中每一个 Pod 的理论 IP 地址，并在内存中建设保护 Pod 节点的路由表

Pod 的多种类型

Pod 存在多种不同的创立类型来满足不一样的用处

ReplicationController

ReplicationController 用来确保容器利用的正本数量始终保持在用户定义的正本数，即如果有容器异样退出，会主动创立新的 Pod 来代替，而如果异样多呈现的容器会主动回收。

ReplicaSet

在新版本 (相对而言的较优形式) 的 Kubernetes 中倡议应用 ReplicaSet 来取代 ReplicationController 来治理 Pod。尽管 ReplicaSet 和 ReplicationController 并没有实质上的不同，只是名字不一样而已，惟一的区别就是 ReplicaSet 反对汇合式的 selector，可供标签筛选。

尽管 ReplicaSet 能够独立应用，但个别还是倡议应用 Deployment 来主动治理 ReplicaSet 创立的 Pod，这样就无需放心跟其余机制的不兼容问题。比方 ReplicaSet 本身并不反对滚动更新(rolling-update)，然而应用 Deployment 来部署就原生反对。

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个申明式定义方法，用来代替以前应用 ReplicationController 来不便且便捷的治理利用。次要的利用场景，包含：滚动降级和回滚利用、扩容和缩容、暂停和持续。

HPA

HPA 仅仅实用于 Deployment 和 ReplicaSet，在 V1 版本中仅反对依据 Pod 的 CPU 利用率扩缩容，在新版本中，反对依据内存和用户自定义的 metric 动静扩缩容。

StatefulSet

StatefulSet 是为了解决有状态服务的问题，绝对于 Deployment 和 ReplicaSet 而已。其次要的应用场景，包含：稳固的长久化存储、稳固的网络标识、有序部署、有序膨胀。

DaemonSet

DaemonSet 确保全副或者一些 Node 下面运行一个 Pod 正本。当有 Node 退出集群的时候，也会为它们新加一个 Pod。当有 Node 从集群中移除的时候，这些 Pod 也会被回收。删除 DaemonSet 将会删除它所创立的所有 Pod。

应用 DaemonSet 的典型场景就是，在每个节点运行日志收集、运行监控零碎、运行集群存储等服务，只有新加进来的节点都须要运行该服务。

Job

Job 负责批处理工作，仅执行一次的工作，它保障批处理工作的一个或者多个 Pod 胜利完结，才会返回胜利。

Cront Job

Cront Job 治理是基于工夫的 Job，即在给定工夫点只运行一次，且周期行的在给定工夫点运行特定工作。

作者: Escape
链接: https://www.escapelife.site/p…