Kubernetes初识

Docker满足了应用资源隔离和依赖管理需求，而Kubernetes则基于Docker等容器运行时（Container Runtime）将底层硬件抽象为同质的资源池, 做了一个基于容器的云操作系统（cloud os)。

我们所作的一切无非就是为了将概念产品尽快变成可交付的服务，因此从编码，测试到部署产生了一系列方法学。虚拟化容器技术（也叫虚拟化运行时 Container Runtime，eg.Docker）极大地减少了系统应用对操作系统环境的污染（ex.一个操作系统安装了python多个版本的编译器），而Kubernetes希望管理这些虚拟化运行时环境，将之扩展到分布式集群环境中。

总览

传统部署时代：之前企业应用直接部署到装有操作系统的物理机上，没有办法定义资源边界，这会造成资源分配问题。比如，多个应用运行在一个物理机上。如果一个应用占据了大量资源，其他的应用性能就减低了。一个解决方案是在每个物理机上运行一个应用，但是资源利用率降低的时候没有办法伸缩。

虚拟化部署时代：虚拟化之后被引入，允许多个虚拟机运行在一个服务器CPU上。虚拟化允许应用通过VM进行资源隔离，并且提供一定程度的安全，因为一个应用不能访问另一个应用的资源。虚拟化的引入提高了物理机的资源利用率，并且提供更好的伸缩性，因为应用可以很容易地添加，更新，减少计算资源。每个VM是一个完全体，里面包括操作系统。

容器化部署时代：容器和虚拟机类似，不过它们之间共享一个操作系统。因此容器是轻量级的。和虚拟机类似，容器有自己的逻辑意义上的文件系统，CPU，内存，网络，进程空间等。因为它只是一种资源描述，和底层基础设施解耦，所以它们能够在云上或者分布式集群环境间移植。

---

为什么需要K8s？

Kubenetes特性

K8S架构图

Master节点的作用

主节点也称control-plane node，主从结构中master节点的角色，相当于集群的控制面板。

主节点负责决策集群事务，比如调度，响应集群事件（e.g. 要求一个应用实例运行3个，突然挂掉一个，系统就会产生一个事件，主节点负责安排重新建一个实例）。

最好就是将主节点都放到一台物理机上，这个物理机不运行任何容器。

Kubernetes Master 组件

1. kube-apiserver
   Master节点上负责暴露Kubernetes API的组件
2. etcd
   K-V数据库，客户端可以监听数据状态的改变。暴露HTTP Restful接口（而不是像MySQL TCP的方式）使得其可以完美接入Kubernetes。
3. kube-scheduler
   调度Pod的进程
4. kube-controller-manager
   管理各种Controller

，例如：
- Node Controller:		负责检查挂掉的节点
- 复制指数Controller: 负责维持每个replication controller对象的Pod数。
- EndPointController:			填充Endpoints对象

这些组件理应放到不同的进程中，但是为了避免复杂，它们都被编译进一个二进制包并运行在同一个进程中。

上面每个组件的构成及分工，下面这张图是这些组件的通信方式：

这里的Container Runtime的一个可选项是Docker。Kubernetes supports several container runtimes: Docker, containerd, cri-o, rktlet and any implementation of the Kubernetes CRI （Container Runtime Interface

---

Scheduler—Pod调度者

scheduler查看新建的未分配节点的Pod。第一步筛选可调度节点（feasible nodes）,第二步对节点进行打分。

Taints & Toleration

Taints是在节点上设置的，用于表示节点的禁忌。比如Master节点不要调度业务Pod。
Toleration是Pod上设置的，用于可以忍受某些Node Taints，以至于该Pod可以调度到有污点的Node上。

---

K8S Object ----配置模式

K8S Object分为Object Spec(用户指定)和Object Status(K8s根据集群状态维护)。
Object Spec中指定一个镜像启动几个实例–replicas这样的信息，K8s集群根据集群状态，更新相应的Status。监护组件发现不满足Spec==Status就做出反应。

---

Security

防御纵深,简称4C。

用户类型

分成服务账户（Service Account）和常规用户(Regular User)两种类型的账户。

常规用户是全局的，也就是可以调用任意命名空间的API。

而服务账户是程序使用的，受限于命名空间。比如命名空间A中的Pod调用API Server的Restful接口时，它的token仅能调用命名空间A的API。

API 调用验证过程

1. Auth(认证阶段) 鉴别用户名（username）
2. Author(授权阶段) 根据Policy来校验请求是否合理，用户需提供 用户名，动作，目标对象
3. 准入控制阶段：这个是可以有多个模块，模块串行校验，与关系，前面通不过，后面连校验机会都没有。

K8s Dashboard

RBAC(基于角色准入控制)

用这个界面可以直接在里面部署应用到K8s集群里。

CNI (Container Network Interface Addon)

一些公有云环境中各物理机之间Pod的互联不用安装任何网络组件,而在私有云（private on-premise cloud)中得添加pod network add-on。这些组件主要为了实现不同Host上的Pod通信，此类产品如：

• Flannel
• Calico
• Weaving Net

The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed. kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).

这些Pod-Network-Addon，提供了为Pod分配IP及 IPAM功能（IP地址段管理)。

---

Volume

K8S的Volume与Docker中的Volume不同，Docker中的Volume只是一个目录，虽然提供了持久化功能，但是不受任何对象生命周期的管理。而在K8S中Volume是和Pod的声明周期是一样的。

Volume在K8S中主要有两个目的：

1. 因为Volume的声明周期比Container长，所以容器重启后可以继续从原来的状态继续。
2. 一个Pod多个Container的场景下，Volume提供文件共享功能。

Reference List

1. Deploying Microservices: Spring Cloud vs. Kubernetes