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

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

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

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

  • Volume -> 集群中的存储卷

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

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

apiVersion: v1kind: Podmetadata:  name: busybox  labels:    app: busyboxspec:  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...