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中的各个名称进行了简单介绍, 再回去看其他文章, 是不是清楚多了. 全部都是对容器的各个方面各个层次的管理.