目录
K8S 的全称是Kubernetes,因为在首字母k和尾字母s中间有8个字母,因此被简写为 K8S(类似的还有i18n等)。它是由谷歌开源的,主流的容器管理平台。
它的 logo 也很有意思,K8S 就像一个舵一样,让用户能够在茫茫大海中将满载集装箱的大船(docker)驶向成功的彼岸。
借助 K8S 提供的能力,运维人员——甚至是前端开发人员——能够很容易地在集群环境中部署和管理容器。并且,对于以下功能,K8S 也能够很好地支持:
在 K8S 中,所有资源都是通过声明式配置进行管理的,它们被称作 K8S 对象。以 namespace 为不同类型的对象所需的配置不完全相同,但他们都应有如下几个基础配置:
常见的 K8S 对象包括 Namespace、Ingress、Sevice、Development、Pod。其中,Namespace 是一个虚拟的概念,用来对集群划分不同的命名空间。通常,同一个 Namespace 中的资源,其命名应该是唯一的。其他几种类型的资源的关系如下图所示:
通常一个集群会包含数台物理主机,它们都是集群的节点,这些节点需要一个统一的 IP 进行访问。Ingress 提供了这项能力,它是整个集群的流量入口。
Ingress 控制器有多种实现,比较常见的是基于 Nginx 实现的。
流量从 Ingress 进入集群之后,应该被分配给不同的容器处理。但通常来说,容器的 IP 不是固定的,这是因为在 K8S 中,可以随时增减容器的数量,此时容器 IP 就是动态的。
Service 是一个抽象概念,它的作用是在 Ingress 和 Pod 之间解藕它们二者的关联。它会动态获取可用的 Pod 的信息,传递给 Ingress,以保证进行正确的负载均衡。
不论是正常的增减容器数量(扩缩容)还是容器自身因为意外重启,流量总会被分配到可用的容器上。
Development 是用于管理副本集和容器配置的。K8S 不建议用户直接操作副本集配置,所以 Development 通常是用户所需要接触的最基础的配置。
通过 Development,可以实现如下功能:
Pod 是 K8S 中最小的部署单元,它包含了一组容器(可以是一个或多个)。同一个 Pod 中的不同容器之间可以通过localhost:
以下是多容器配合的一个实例:
上图中的 Web Server 容器可以对外提供资源访问的服务,同时,File Puller 作为一个 sidecar 容器,可以同时将远端的内容更新到本地存储中,以保证 Web Server 提供的内容是最新的。
k8s集群由Master节点和Node(Worker)节点组成。
Master节点指的是集群控制节点,管理和控制整个集群,基本上k8s的所有控制命令都发给它,它负责具体的执行过程。在Master上主要运行着:
除了master以外的节点被称为Node或者Worker节点,可以在master中使用命令 kubectl get nodes查看集群中的node节点。每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,该节点上的工作负载就会被Master自动转移到其它节点上。在Node上主要运行着: