Node
Node 很好理解，就是服务实际运行的实例, 可以是一台物理机, 也可以是一台 VM 虚拟机。
Pod
docker 我们都知道是容器，而 Pod 其实就类似于 docker-composer , 多个的相关联的容器组成了一个 Pod. 比如有一个 nginx 容器和一个 php-fpm 的容器, 他们两个就可以组合为一个Pod。
在同一个 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。
ReplicaSet
与ReplicationController 的功能差不多, 额外增加了集合式 selector 的支持(标签选择器)。虽然 ReplicaSet 可以单独使用, 但建议用 Deployment 进行管理。
Deployment
Deployment 不会直接管理 Pod, 而是通过管理 ReplicaSet，再经由 ReplicaSet 管理 Pod。Deployment 处理了很多 ReplicaSet 不支持的额外操作. 如:
- rolling-update (滚动更新) 和回滚
- 自动伸缩(扩容和缩容)
- 暂停和继续
Deployment 热更新就是通过新建一个 ReplicaSet 逐渐减少原来 ReplicaSet 中 Pod 数量并增加新 ReplicaSet 中 Pod 数量来实现的，回滚则反之。
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 还能够对流量进行负载均衡。
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/
