Kubernetes各个组件的概念

前言

Kubernetes中的概念太多了, 什么Pod Service Deployment 等等等等, 给刚接触的我都整蒙了. 通过几天观察下来, 说一下我对各个组件的理解.

此文章仅仅对这些概念做一个简单的介绍, 不至于后面看其他文章的时候一头雾水.

以下所有的类型, 均可以通过命令: kubectl explain [名称] 来查看其含义以及配置文件的内容.

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控制器. 以下控制器只是实现了不同的需求, 简单过一下即可.

ReplicationController

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

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/

存储卷

这个需求就很普遍了, 用来对数据进行存储及挂载服务. 在不同的容器、以及不同的pod中进行共享.

具体的使用方式可见: https://hujingnb.com/archives/709

ConfigMap

专门用于存储配置文件, 同时还支持二进制内容. 将文件内容直接写入到yaml配置中. 同时, ConfigMap是支持热更新的.

Secret

存储一些需要加密的信息, 比如密钥、密码等. 其基本上和ConfigMap差不多, 区别就是在ConfigMap的基础上对内容做了一次加密. 不过不过, 现阶段Secret的加密方式就是base64? 这也叫加密? 只能算作编码吧.

可以通过命令: kubectl get secrets secret-name -o yaml查看内容.

不过, 社区后续应该会推出更安全的加密策略.

另外, 对于私有的镜像仓库, Secret可以添加拉取镜像时的鉴权信息.

volume

在同一个pod下的多个容器之间共享存储卷, 就跟磁盘的挂载差不多啦. volume没有单独的kind, 是直接进行定义的.

---

如上, 对Kubernetes中的各个名称进行了简单介绍, 再回去看其他文章, 是不是清楚多了. 全部都是对容器的各个方面各个层次的管理.