【百度云原生导读】在上一节课我们学习了 Docker 的相关基础知识，解决了应用之间的隔离机制。但是在架构上，Docker仍然是一个单机的引擎，在真实的生产环境中我们可能拥有着海量的机器，那么如何管理、调度、编排这些分布在不同机器上的容器就成为了新的问题。因此，Kubernetes 就应运而生了。
本文是基于『云原生基础知识概述及实践』系列视频课程——『Kubernetes 入门—Kubernetes工作原理及使用』进行的文字梳理，视频课程可点击【阅读原文】进行学习。
Kubernetes 的前身其实是 Google 的 Ball，2013年开源之后发展至今，已成为了开源事件部署引擎的事实标准。
本节课主要分为以下三大部分：
第一部分：Kubernetes 架构剖析
对 Kubernetes 核心组件分析。
第二部分：快速搭建 Kubernetes 集群
使用 Kubeadm 搭建 Kubernetes 环境。
第三部分：Demo
演示如何操作一个 Pod。
1. Kubernetes 核心组件分析
1.1 核心概念：Pod
-
Pod 是 Kubernetes 中最小的可部署的计算单元
-
这样的一组容器被“打包”到一起组成了一个Pod 并接受 Kubernetes 的调度，编排等控制逻辑。
-
为了让大家更好的理解“一组容器“的概念，接下来为大家详细剖析 Pod 的内部架构。
Pod 的内部架构
![]()
蓝色部分代表的是整个 Pod。其中右上角的net namespace 是 Pod 级别的 namespace，它代表了 Pod 中的所有容器。
图中有4个 Container（即：PauseContainer/Container A/Container B/Container C/），他们在创建的时候都被加入到了 namespace 当中。
那么，Pod 级别的 Container 是从哪里来的呢？从图中可以看到，真正工作的 Container 我们把它标注为 A，B，C。Pause Container 的作用相当于一个占位符。当我们创建 Pod 的时候，会首先创建一个 Pause Container。该容器创建出来的namespace，就相当于整个 Pod 的 namespace。然后后面的容器再创建出来（比如说Container A/B/C）这些容器在创建出来的时候，就都会选择加入到 Pause Container 创建出来的 net namespace 当中。
当然，也不是所有的 namespace 都是不隔离的。Container 左侧是一个 image，每一个 container 都有一个镜像，每一个镜像又相当于一个容器的 Root ffs。既然每个容器的 Root ffs 是不相同的，那么显而易见，mnt namespace 就是隔离的。
这样我们就可以清楚地看到，哪些 namespce 在 Pod 当中是互相隔离的，而哪些是在 Pod 级别当中共享的。
Pod 在 Kubernetes 中的展现形式
![]()
通常，我们习惯用 Yaml 来描述 Kubernetes 里的资源。Yaml 中的内容其实就是我们对资源参数的描述。
我们先看 Pod 在 Yaml 中的前四行。这四行是资源在 Yaml 中的通用字段。ApiVersion/kind 用于表示 Kubernetes 的资源类型是什么。通过 metadata 来声明资源的源数据。Spec 字段和资源类型是强相关的了。不同的资源会有不同的 spec 定义。那在 Pod 资源当中，最核心的是关于容器的定义了。
下面几行，关于容器的定义，是一个数组类型的，这也符合我们对 Pod 的定义：即它是由一组容器形成的。这些字段包含：声明容器镜像，启动容器的命令，容器镜像的拉取方式，以及容器的名称。
1.2 核心概念 Kubelet
Kubelet 是 Kubernetes 集群的“节点代理”。也可以说是 Kubernetes 部署在每个节点的agent。
Kubelet 启动后会向 Kubernetes 集群注册自己，并上报节点的相关信息。此时在 Kubernetes 集群中就增加了一台新的可用的 Node 节点（可能是一个物理机，也可能是一个虚拟机，甚至是一个容器）。
Kubelet 发现有属于自己节点的 Pod 符合创建条件后，会按照Pod声明的配置去启动容器。
1.3 Kubernetes 控制面的相关组件
![]()
上面这张图分为3个部分作介绍：
1. 下半部分：也就是之前介绍过的Kubelet/Pod。
2. 左上角：Kubectl。也就是Kubernetes 的命令行工具。可以通过Kubectl来提交资源的Yaml 给Kubernetes 集群。也可以进行一系列的运维操作。
3. 右面：Master 节点。也就是Kubernetes 控制面的相关组件了。其中，API Sever是Kubernetes 中所有源数据的集成入口。也是整个Kubernetes 集群的中枢组件。其他组件（包括Controller, Scheduler等）在获取数据都需要和API Sever 打交道。API Sever 也会接受这些组件的协入请求，并最终将数据写入ETCD 当中。同时，API Sever 也会缓存所有的源数据。当其他组件发起“读”请求时，就会将数据直接从内存中发给对方。尽量避免ETCD 成为系统的瓶颈。除了源数据存储功能，API Server 还提供了一个Watch 机制。能够主动推送某种资源的变化。而Scheduler会向API Sever 注册并且监听Pod 的资源变更事件。Scheduler 整体的调度逻辑可以简化并概括为两个：过滤、打分。
每次对Pod进行调度的时候，首先将不符合条件的Node（如：机器上已经没有资源了，不符合某些标签，选择器的要求等）过滤掉。过滤完成后我们得到一个符合要求的Node列表，Scheduler 会通过打分算法，来计算每一个Node 的分数。最终选择一个得分最高的节点做为Pod 需要绑定的节点。最终Scheduler 会将结果回写到API Sever 当中。
编排组件：Controller。Controller 通过几种固定的workload。通过控制器的方式，来完成运行时服务器的编排工作。
2. 快速搭建 Kubernetes 集群
2.1 搭建工具：Kubeadm 简介
Kubeadm 是 Kubernetes 官方提供的用于快速安装 Kubernetes 集群的工具。
下图是 Kubeadm 的配置文件
![]()
在配置文件当中，我们指定了 dns 的类型，ETCD 存储目录以及要创建的 Kubernetes 的版本以及相关的参数。
2.2 搭建环境
初始 Master 节点
Kubeadm init—config kubeadm.conf
![]()
安装 flannel cni
https://raw.githusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
![]()
3. Demo：演示如何操作一个 Pod
创建一个 Namespace
Kubectl create namespace demo
创建 Pod
Kubectl apply –f pod.yaml
查看 Pod 运行状态
Kubectl describe pods demo-pod–n demo
查看 Pod 输出日志
Kubectl logs demo-pod –n demo
查看 Pods 列表
Kubectl get pods-n demo
删除 Pod
Kubectl delete-f pod.yaml
(创建Deomo的详细过程欢迎大家观看课程的视频回放。)
MoreCommand
Basic Commands: create，expose, run, setBasic Commands: explain, get，edit，deleteDeploy Commands: rollout，scale，autoscale
4. 总结
本节课作为云原生入门系列课程第二节。重点介绍了 Kubernetes 出现的背景和作用、Kubernetes 的特点和核心架构、Kubernetes 每一个模块承担的作用以及实现的功能。并演示了如何搭建一个单节点的 Kubernetes 环境以及如何使用来操作相关的资源，希望对大家有所帮助。
视频课程：https://www.bilibili.com/video/BV17o4y1R77k
免费领小度智能屏！暖春福利进行ing
![]()
