Node

Node 很好理解，就是服务实际运行的实例, 可以是一台物理机, 也可以是一台 VM 虚拟机。

Pod

docker 我们都知道是容器，而 Pod 其实就类似于 docker-composer , 多个的相关联的容器组成了一个 Pod. 比如有一个 nginx 容器和一个 php-fpm 的容器, 他们两个就可以组合为一个Pod。

pod和docker之间通信 docker和pod关系_kubernetes

在同一个 Pod 中, 不同容器共享网络栈与存储卷。也就是说, nginx 访问 php-fpm 可以直接使用 localhost:9000 即可, 也就是说, 一个 Pod 中启动两个容器, 都占用 80 端口, 是无法成功启动的. 共享是通过Pause容器实现的。

Pod 控制器

在 Kubernetes中, Pod 是资源的最小单位了. 而这一堆控制器, 就是用来对 Pod 进行自动管理的。

  • 管理Pod的数量
  • 实现Pod的弹性伸缩
  • 监控Pod的状态
  • 定时启动并释放Pod

为了实现不同的需求, 出现了不同的 Pod 控制器. 以下控制器只是实现了不同的需求而已，本质上都是用来对最小单元即 Pod 的控制。

ReplicationController#

对 Pod 数量进行管理. 确保 Pod 数量保持在用户定义的数量. (若容器异常退出, 自动创建新的 Pod 若数量多了, 也会自动回收. ) 不过现在建议使用 ReplicaSet 替代ReplicationController。

pod和docker之间通信 docker和pod关系_容器_02

 ReplicaSet#

与 ReplicationController 的功能差不多, 额外增加了集合式 selector 的支持(标签选择器)。虽然 ReplicaSet 可以单独使用, 但建议用 Deployment 进行管理。

Deployment#

Deployment 不会直接管理 Pod, 而是通过管理 ReplicaSet，再经由 ReplicaSet 管理 Pod。Deployment 处理了很多 ReplicaSet 不支持的额外操作. 如:

  • rolling-update (滚动更新) 和回滚
  • 自动伸缩(扩容和缩容)
  • 暂停和继续

 Deployment 热更新就是通过新建一个 ReplicaSet 逐渐减少原来 ReplicaSet 中 Pod 数量并增加新 ReplicaSet 中 Pod 数量来实现的，回滚则反之。

pod和docker之间通信 docker和pod关系_linux_03

 HorizontalPodAutoscaler#

HPA 也不会直接管理 Pod，而是管理 Deployment 或者 ReplicaSet。HPA 可以检测 Pod 资源使用率。可以实现这样的场景：当Pod CPU 使用率大于 80 则自动新建，否则自动释放同时启动的 Pod 数量最多 30 个，最少 5 个即实现服务的水平扩展。

StatefulSet#

StatefulSet 是为了解决有状态服务的. 上面的控制器都是无状态的. StatefulSet 可以实现如下功能:

  • 稳定的持久化存储. 当 Pod 动态调整后能够访问到相同的持久化数据. 基于 PVC 实现
  • 稳定的网络标识. Pod 动态调整后 PodName HostName 不变. 基于 Headless Service实现.
  • 有序部署. 既前一个 Pod 启动成功, 才会创建下一个 Pod. 解决服务依赖的问题. 基于 init containers 实现.
  • 有序删除. 有序部署的反向操作.

DeamonSet#

可以确保所有(或指定的一部分) Node 都运行一个 Pod 副本. 当新 Node 加入集群时自动新增对应的 Pod, 当 Node 从集群移除时, 对应的 Pod 也会被回收。这种运行在 Node 中的 Pod 有什么用呢? 比如资源监控, 再比如日志收集等等.

Job#

批处理任务. kubernetes可以保证此任务的一个或多个Pod成功结束, 若任务失败, kubernetes会自动重启, 直到成功.

CronJob#

Job的crontab版本. 基于时间管理的Job. 是通过在特定时间创建Job实现的. 可以在指定时间运行一次任务, 或者周期性的在指定时间运行.

服务发现及负载均衡

Service#

Pod 控制器只是对 Pod 的管理, 比如在一个 Deployment 中运行了 5 个 Pod, 如果外部访问 Pod 服务时写的是每一个 Pod 的地址, 当 Pod 动态伸缩的时候, 维护这些地址就是一个让人头大的问题了.而 Service 就是为了解决这个问题而出现的. 它为一组 Pod 提供了一个统一对外的接口, 外部访问 Service 再经由 Service 将请求发给 Pod, 而不需要关心 Pod 的数量、启动、释放等等。同时 Service 还能够对流量进行负载均衡。

pod和docker之间通信 docker和pod关系_容器_04

 Ingress#

因为 Service 是四层负载均衡, 也就是说只能代理到 IP 层, 无法实现像 nginx 一样根据不同域名不同路径进行负载均衡. 为了解决这个问题而提出了 Ingress, Ingress 是独立与其他服务对请求进行转发的. 可以将其理解为 Service 的 Service。一般来说, 通过 Service 对 Pod 进行内部代理, 然后通过 Ingress 将请求转发给 Service. Ingress 也有不同的实现, 而其中比较常用的就是 ingress-nginx 了,其配置文件类似与 nginx. 由官方维护的. 启动命令为：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/cloud/deploy.yaml

官方文档：https://kubernetes.github.io/ingress-nginx/

pod和docker之间通信 docker和pod关系_linux_05