Kubernetes 入门之知识点梳理
最近在挺哥的指导下学习 Kubernetes,会定期写一些学习总结和大家分享,本篇文章是第一篇,从介绍 k8s 知识点和常见名词开始。
k8s 中作为大脑存在的是 Master 节点,是集群的控制节点,负责整个集群的管理和控制。所有的其他 Node 都会向 Master 注册自己,并定期上报自身的所有信息。在 Master 节点上运行着下面 4 种进程:
kubectl
就是直接对 Api Server 负责;除了 Master 节点外,其他的节点都称为 Node,即工作节点,且接受 Master 的控制。Node 超过指定时间不上报信息时,会被 Master 判定为失联,则该 Node 的状态被标记为不可用,随后 Master 会触发"工作负载大转移"的自动流程。而 Node 上运行着下面 3 种主要的进程:
用于实现多租户的资源隔离。通过将集群内部的资源对象分配到不同的 Namespace 中。创建资源对象时可以指定属于哪个 Namespace。
Pod 是 k8s 的最小调度单元。
如上图所示,而 Pod 是由一个个容器组成的,称为容器组。而组成 Pod 的容器分为 Pause 容器和一个个业务容器。其中以 Pause 容器的状态代表整个 Pod 的状态,由于 Pause 容器不易死亡,这样就能保证对 Pod 这个整体的状态的判断;而所有的业务容器共享 Pause 的 IP 和 Volume,这样就解决了联系紧密的业务容器之间的通信和共享资源的问题。Pod 在哪个 Node 上工作是由 kubelet 调度的。
Pod 拥有唯一 IP ,k8s 以 Endpoint (pod_ip + containerPort) 作为 Pod 中一个服务进程的对外通信地址。而任意两个 Pod 之间直接 TCP/IP 通信,采用虚拟二层网络技术实现,如 Flannel、Openvswitch。而 Pod 的 Endpoint 与 Pod 同生命周期,当 Pod 被销毁,对应的 Endpoint 也随之被销毁。
Pod 有两种类型:
定义在 Pod 上,被一个 Pod 里的多个容器挂载到具体文件目录下。需要注意的是 Volume 与 Pod 的生命周期相同。
作用:Pod 中多个容器共享文件;让容器的数据写到宿主机的磁盘上;写文件到网络存储中;容器配置文件集中化定义与管理。
emptyDir
Pod 分配到 Node 上时创建,无需指定宿主机上的目录文件。Pod 被移除时,emptyDir 上的数据被永久删除。
hostPath
在 Pod 上挂载宿主机上的文件或目录。在不同 Node 上具有相同配置的 Pod 可能会因为宿主机上的目录和文件不同而导致对 Volume 上目录和文件的访问结果不一致;若使用了资源配额管理, k8s 无法将 hostPath 在宿主机上使用的资源纳入管理。
用途:容器生成的日志文件需要永久保存;需要访问宿主机上 Docker 引擎,将 hostPath 定义为宿主机 /var/lib/docker 目录。
其他
如 gcePersistentDisk 、 awsElasticBlockStore 等,都是由特定的云服务提供的永久磁盘。Pod 结束时不会被删除,只会被卸载。使用时需要按照要求安装特定虚拟机和永久磁盘。
用于更好地解决 Pod 的编排问题,其内部使用 ReplicaSet 来实现目的。
使用场景:
Pod 数量的描述
定义形式:key=value。我们主要使用 Label Selector 来查询和筛选某些 Label 的资源对象。
使用场景:
定义形式:key=value
与 Label 的区别:
使用场景:
Replica Set(RS) 是 Replication Controller(RC) 的升级版本。两者的唯一区别是对选择器的支持。ReplicaSet 支持 labels user guide 中描述的 set-based 选择器要求, 而 Replication Controller 仅支持 equality-based 的选择器要求。
我们一般用 Deployment 来定义 RS,很少直接创建 RS,从而形成一套完整的 Pod 的创建、删除、更新的编排机制。
RS 中可以定义的是:Pod 期待的副本数(Replicas);用于筛选目标 Pod 的 Label Selector;当 Pod 副本数小于预期数量时,用于创建新 Pod 的模板。
Master 的 Controller Manager 定期巡检系统中当前存活的目标 Pod,确保目标 Pod 实例数等于期望值。删除 RS 不会影响 Pod ,支持基于集合的 Label Selector;通过改变 RS 中 Pod 副本数量,实现 Pod 扩容和缩容;通过改变 RS 中 Pod 模板中的镜像版本,实现 Pod 的滚动升级。
定义:微服务架构中的微服务。
Service 定义了一个服务的访问入口地址,客户端通过该入口地址访问背后的集群实例。Service 通过 Label Selector 与后端 Pod 副本集群之间实现对接。Service 之间通过 TCP/IP 通信。
kube-proxy 进程是一个智能的负载均衡器,负责将对 Service 的请求转发到后端的 Pod。Pod 的所有副本为一组,提供一个对外的服务端口,将这些 Pod 的 Endpoint 列表加入该端口的转发列表。客户端通过负载均衡的对外 IP + 服务端口来访问此服务。
Service 拥有全局唯一虚拟 IP,称为 ClusterIP,每个 Service 变成了具备全局唯一 IP 的通信节点。与 Pod 不同的是,Pod 的 Endpoint 会随 Pod 的销毁而发生改变,但 ClusterIP 在 Service 的生命周期中不会发生改变。并且只要用 Service 的 Name 与 Service 的 ClusterIP 做一个 DNS 域名映射,即可实现服务发现。
Service 中一般会定义一个 targetPort,即提供该服务的容器暴露的端口,具体业务进程在容器内的 targetPort 上提供 TCP/IP 接入;而 Service 的 port 属性定义了 Service 的虚接口。
before:每个 Service 生成一些对应的 Linux 环境变量,Pod 容器启动时自动注入。
now:通过 Add-On 增值包的方式引入 DNS 系统,将服务名作为 DNS 域名即可实现。
k8s 中有三种类型的 IP:
Node IP
集群中每个节点的物理网卡的 IP 地址;所有属于这个网络的服务器之间都通过这个网络直接通信;集群之外的节点访问该集群时,必须通过 Node IP 通信。
Pod IP
Docker Engine 根据 docker0 网桥的 IP 地址段进行分配的;虚拟的二层网络;不同 Pod 的容器之间互相访问时,通过 Pod IP 所在的虚拟二层网络进行通信。
Cluster IP
k8s 中实现外部系统访问 Service 的方法,主要是通过 NodePort,其实现方式是在每个 Node 上为需要提供外部访问的 Service 开启一个对应的 TCP 监听端口。此时,外部系统只要用任意一个 Node 的 IP + NodePort 即可访问此服务。