一、概述

Kubernetes 中的大部分概念如 Node 、 Pod 、 Replication Controller 、 Service 等都可以看作一
种“资源对象”，几乎所有的资源对象都可以通过 Kubernetes 提供的 kubectl 工具（或者 API 编程调用）执行增、删、改、查等操作并将其保存在 etcd 中持久化存储。

从这个角度来看，Kubernetes 其实是一个高度自动化的资源控制系统，它通过跟踪对比 etcd 库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

Service 的服务进程目前都基于 Socket 通信方式对外提供服务，比如 Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的 TCP Server 进程，虽然一个

Service 通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的 Endpoint

（ IP+Port）访问点。但 Kubernetes 能够让我们通过 Service（虚拟 Cluster IP +Service Port）连接到指定的 Service 上，有了 Kubernetes 内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们

对服务的正常调用。

二、 Kubernetes 集群的两种管理角色：Master 和 Node

1、Master

1.1、master概念

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

1.2、master节点上运行的进程

①、Kubernetes API Server（kube-apiserver）

作用：提供了 HTTP Rest 接口的关键服务进程，是 Kubernetes 里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。

②、Kubernetes Controller Manager（kube-controller-manager）

作用：Kubernetes 里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。

③、Kubernetes Scheduler（kube-scheduler）

作用：负责资源调度（Pod 调度）的进程，相当于公交公司的“调度室”。

④、etcd服务

作用：Kubernetes 里的所有资源对象的数据存储位置。

2、Node

2.1、node概念

除了 Master ， Kubernetes 集群中的其他机器被称为 Node 节点，Node 节点才是 Kubernetes 集群中的工作负载节点。每个 Node 都会被 Master 分配一些工作负载（ Docker 容器），当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上去。

2.2、node节点上运行的进程

①、kubelet

作用：负责 Pod 对应的容器的创建、启停等任务，同时与 Master 节点密切协作，实现集群管理的基本功能。

②、kube-proxy

作用：实现 Kubernetes Service 的通信与负载均衡机制（L4层的负载均衡）的重要组件

③、Docker Engine（docker）

作用：Docker 引擎，负责本机的容器创建和管理工作

三、kubernetes实现高效均衡的资源调度策略的方式

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

四、Pod

1、pod中容器有几种

名称	作用
init容器	初始化容器环境
pause容器（根容器）	在pod内提供network namespace和存储卷支持
业务/应用容器	提供业务运行

2、pod的类型

2.1、普通的Pod

普通的 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定（ Binding ），随后该 Pod 被对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。

在默认情况下，当 Pod 里的某个容器停止时， Kubernetes 会自动检测到这个问题并且重新启动这个 Pod （重启 Pod 里的所有容器），如果 Pod 所在的 Node 宕机，则会将这个 Node 上的所有p od 重新调度到其他节点上

2.2、静态的Pod

创建后并不存放在Kubernetes 的 etcd 存储里，而是存放在某个具体的 Node 上的一个具体文件中，并且只在此 Node 上启动运行

五、Replication Controller（RC）

1、replication controller 概念

RC 是 Kubernetes 系统中的核心概念之一，简单来说，它其实是定义了一个期望的场景，即声明某种 Pod 的副本数量在任意时刻都符合某个预期值。

2、replication controller的组成部分

①、pod期待的副本数

②、用于筛选目标pod的lable selector

③、当pod的副本数小于预期数量时，用于创建新pod的pod模板

3、replication controller的重要性

当我们定义了一个 RC 并提交到 Kubernetes 集群中以后， Master 节点上的 Controller Manager

组件就得到通知，定期巡检系统中当前存活的目标 Pod ，并确保目标 Pod 实例的数量刚好等于

此 RC 的期望值，如果有过多的 Pod 副本在运行，系统就会停掉一些 Pod ，否则系统就会再自

动创建一些 Pod 。可以说，通过 RC ， Kubernetes 实现了用户应用集群的高可用性，并且大大减

少了系统管理员在传统 IT 环境中需要完成的许多手工运维工作

六、Label（标签）

1、label 概念

Label 是 Kubernetes 系统中另外一个核心概念。一个 Label 是一个 key=value 的键值对，其中 key 与 value 由用户自己指定。

我们可以通过给指定的资源对象捆绑一个或多个不同的 Label 来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。

Label 相当于我们熟悉的“标签”，给某个资源对象定义一个 Label，就相当于给它打了一个标签，随后可以通过 Label Selector （标签选择器）查询和筛选拥有某些 Label 的资源对象，Kubernetes 通过这种方式实现了类似 SQL 的简单又通用的对象查询机制。

七、StatefulSet和Deployment

statefulSet：部署的是有状态的应用

deployment：部署的是无状态的应用

八、Endpoint

它代表着此 Pod 里的一个服务进程的对外通信地址。一个 Pod 也存在着具有多个Endpoint 的情况，比如当我们把 Tomcat 定义为一个 Pod 时，可以对外暴露管理端口与服务端口这两个 Endpoint，Endpoint实际是( pod IP + container Port )

九、server（服务）

1、概述

Service 也是 Kubernetes 里的最核心的资源对象之一， Kubernetes 里的每个 Service 其实就是

我们经常提起的微服务架构中的一个“微服务”。

2、server 是怎样和后端的Pod副本集群通信的

Service 与其后端 Pod 副本集群之间则是通过 Label Selector 来实现“无缝对接”的。

3、RC（replication controller 副本控制器）对server看来的作用

RC 的作用实际上是保证 Service 的服务能力和服务质量始终处于预期的标准。

4、多个pod副本组成一个集群来提供服务，客户端是怎样访问他们的

前置：

每个 Pod 都会被分配一个单独的 IP 地址，而且每个 Pod 都提供了一个独立的 Endpoint （Pod IP（Cluster IP）+ContainerPort）以被客户端访问，现在多个 Pod 副本组成了一个集群来提供服务

访问方法：

一般的做法是部署一个负载均衡器（软件或硬件），为这组 Pod 开启一个对外的服务端口如 8000 端口，并且将这些 Pod 的 Endpoint 列表加入 8000 端口的转发列表中，客户端就可以通过负载均衡器的对外 IP 地址 +服务端口来访问此服务，而客户端的请求最后会被转发到哪个 Pod ，则由负载均衡器的算法所决定。