Kubernetes 入门：基本概念梳理

《Kubernetes 入门：基本概念梳理》最先发布在 blog.hdls.me/15346044250…

本篇文章介绍了 k8s 基本知识点和常见名词。

Master

k8s 中做为大脑存在的是 Master 节点，是集群的控制节点，负责整个集群的管理和控制。全部的其余 Node 都会向 Master 注册本身，并按期上报自身的全部信息。在 Master 节点上运行着下面 4 种进程：

• Api Server ：提供 HTTP Rest 接口的服务进程；全部资源的增删改查操做的惟一入口；集群控制的入口， kubectl 就是直接对 Api Server 负责；
• Controller Manager ：全部资源对象的自动化控制中心；
• Scheduler ：负责资源的调度，主要将 Pod 调度到指定的 Node 上；
• etcd Server ：全部资源对象的数据保存在 etcd 中。

Node

除了 Master 节点外，其余的节点都称为 Node，即工做节点，且接受 Master 的控制。Node 超过指定时间不上报信息时，会被 Master 断定为失联，则该 Node 的状态被标记为不可用，随后 Master 会触发"工做负载大转移"的自动流程。而 Node 上运行着下面 3 种主要的进程：

• kubelet ：负责 Pod 对应的容器的建立、启停等任务；与 Master 节点密切合做，实现集群管理的基本面功能，Node 向 Master 上报信息，就是经过 kubelet 实现的；
• kube-proxy ：实现 Service 的通讯与负载均衡机制；
• Docker Engine ：负责本机容器的建立与管理。

Namespace

用于实现多租户的资源隔离。经过将集群内部的资源对象分配到不一样的 Namespace 中。建立资源对象时能够指定属于哪一个 Namespace。

Pod

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 ，存放在 etcd 中，被调度到 Node 中进行绑定，调度后被 Node 中的 kubelet 实例化成一组容器并启动；
• 静态 Pod ，存放在某个具体的 Node 上的一个具体文件中，只在此 Node 中启动运行。

Volume

定义在 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 结束时不会被删除，只会被卸载。使用时须要按照要求安装特定虚拟机和永久磁盘。

Deployment

用于更好地解决 Pod 的编排问题，其内部使用 ReplicaSet 来实现目的。

使用场景：

• 生成 RS 并完成 Pod 副本的建立过程；
• 检查部署动做是否完成；
• 更新 Deployment 以建立新的 Pod；
• 回滚；
• 挂起或恢复。

Pod 数量的描述

• DESIRED：Pod 副本数量的指望值
• CURRENT：当前的副本数
• UP_TO_DATE：最新版本的 Pod 副本数
• AVAILABLE：当前集群中可用 Pod 副本数

Label

定义形式：key=value。咱们主要使用 Label Selector 来查询和筛选某些 Label 的资源对象。

使用场景：

• kube-controller 筛选要监控的 Pod
• kube-proxy 进程创建 Service 对 Pod 的请求转发路由表
• kube-scheduler 进程实现 Pod 定向调度

Annotation

定义形式：key=value

与 Label 的区别：

• Label 有严格命名规则
• Label 定义的是 metadata ，且用于 Label Selector；Annotation 是用户任意定义的附加信息

使用场景：

• build 信息、 release 信息、 Docker 镜像信息等
• 日志库、监控库、分析库等资源库的地址信息
• 程序调试工具信息
• 团队的联系信息

Replica Set

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 定义了一个服务的访问入口地址，客户端经过该入口地址访问背后的集群实例。Service 经过 Label Selector 与后端 Pod 副本集群之间实现对接。Service 之间经过 TCP/IP 通讯。

负载均衡

kube-proxy 进程是一个智能的负载均衡器，负责将对 Service 的请求转发到后端的 Pod。Pod 的全部副本为一组，提供一个对外的服务端口，将这些 Pod 的 Endpoint 列表加入该端口的转发列表。客户端经过负载均衡的对外 IP + 服务端口来访问此服务。

ClusterIP

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 域名便可实现。

外部系统访问 Service

k8s 中有三种类型的 IP：

• Node IP

  集群中每一个节点的物理网卡的 IP 地址；全部属于这个网络的服务器之间都经过这个网络直接通讯；集群以外的节点访问该集群时，必须经过 Node IP 通讯。

• Pod IP

  Docker Engine 根据 docker0 网桥的 IP 地址段进行分配的；虚拟的二层网络；不一样 Pod 的容器之间互相访问时，经过 Pod IP 所在的虚拟二层网络进行通讯。

• Cluster IP

  • 仅仅做用于 Service ：由 kuber 管理和分配 IP 地址；
  • 没法被 ping：由于没有一个实体网络对象来响应；
  • Cluster IP 只能结合 Service Port 组成一个具体的通讯端口：单独的 Cluster IP 不具有 TCP/IP 通讯基础；属于 kuber 集群的封闭空间；集群外的节点若须要访问，须要一些额外的操做；
  • Node IP 网、Pod IP 网和 Cluster IP 网之间的通讯是 kuber 自制的一种编程方式的路由规则；

k8s 中实现外部系统访问 Service 的方法，主要是经过 NodePort，其实现方式是在每一个 Node 上为须要提供外部访问的 Service 开启一个对应的 TCP 监听端口。此时，外部系统只要用任意一个 Node 的 IP + NodePort 便可访问此服务。