Kubernetes 基本概念和术语

Kubernetes 中大部分概念如 Node、Pod、Replication Controller、 Service 等都可以看做一种 "资源对象"，几乎所有的资源对象都可以通过 Kubernetes提供的 kubectl 工具(或者API远程调用)执行增、删、查、改等操作并将其保存在etcd中持久化存储。从这个角度来看，Kubernetes其实是一个高度自动化的资源控制系统，它通过追踪对比etcd库里保存的"资源期望状态"与当前环境中"实际资源状态"的差异来实现自动控制和自动纠错的高级功能。

在介绍资源对象之前，我们先了解一下Kubernetes集群的两种管理角色: Master 和 Node。

1、Master

Kubernetes里的 Master指的是集群控制节点，每个 Kubernetes集群里需要有一个 Master节点来负责整个集群的管理和控制，基本上 Kubernetes的所有控制命令都发给它，它来负责具体的执行过程，我们后面执行的所有命令基本都是在 Master节点上运行的。 Master节点通常会占据一个独立的服务器(高可用部署建议用3台服务器)，其主要原因是它太重要了，是整个集群的“首脑”，如果宕机或者不可用，那么对集群内容器应用的管理都将失效。

Master节点上运行着以下一组关键进程。

Kubernetes API Server(kube-apiserver)：提供了 Http Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
Kubernetes Controller Manager( kube-controller-manager)：Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。
Kubernetes Scheduler( kube-scheduler)：负责资源调度(Pod调度)的进程，相当于公交公司的“调度室”。

另外，在 Master节点上还需要启动一个etcd服务，因为 Kubernetes里的所有资源对象的数据全部是保存在etcd中的。

2、Node

除了 Master， Kubernetes集群中的其他机器被称为Node节点，在较早的版本中也被称为Minion。与 Master一样，Node 节点可以是一台物理主机，也可以是一台虚拟机。Node节点才是 Kubernetes集群中的工作负载节点，每个Node都会被 Master分配一些工作负载( Docker容器)，当某个Node宕机时,其上的工作负载会被 Master自动转移到其他节点上去。

每个Node节点上都运行着以下一组关键进程。

kubelet：负责Pod对应的容器的创建、启停等任务，同时与 Master节点密切协作，实现集群管理的基本功能。
kube-proxy：实现 Kubernetes Service 的通信与负载均衡机制的重要组件。
Docker Engine( docker)：Docker引擎，负责本机的容器创建和管理工作。

Node节点可以在运行期间动态增加到 Kubernetes集群中，前提是这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下 kubelet会向 Master注册自己，这也是 Kubernete推荐的Node管理方式。一旦Node被纳入集群管理范围， kubelet进程就会定时向 Master节汇报自身的情报，例如操作系统、 Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样 Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息时，会被 Master判定为“失联”，Node的状态被标记不可用( Not Ready)，随后Master会触发“工作负载大转移”的自动流程。

我们可以执行下述命令查看集群中有多少个Node:

[root@localhost ~]# kubectl get nodes 

NAME        STATUS    AGE

127.0.0.1   Ready     6h

[root@localhost ~]#

然后，通过kubectl describe node < node_name > 来查看某个Node的详细信息。