作者简介

星龙                                      

百度基础架构部研发工程师

负责混部调度系统研发

本文基于百度云原生团队『云原生基础知识概述及实践』系列视频课程——『Kubernetes 入门—Kubernetes 工作原理』梳理.

视频课程可点击：https://cloud.baidu.com/video-center/video.html?id=607进行学习。

导读

在上一节课我们学习了 Docker 的相关基础知识。（Kubernetes入门——深入浅出讲Docker）Docker 解决了应用之间的隔离问题，但是在架构上，Docker 仍然是一个单机的引擎。在真实的生产环境，我们可能拥有着海量的机器。那么如何管理、调度、编排这些分布在不同机器上的容器，就成为了新的问题。在这个时候，Kubernetes 就应运而生了。

第一部分：Kubernetes 架构剖析

第二部分：快速搭建 Kubernetes 集群

第三部分：Demo

演示如何操作一个 Pod

在单机上，我们通常会把某个应用程序打包并部署在 Docker 容器当中。但在真实的环境中，问题往往比这复杂很多。我们需要解决服务的高可用问题、服务之间的依赖问题。

所以说 Kubernetes 不仅考虑的是容器级别的部署和编排，更多面向的是更高层面（比如应用层）的编排和部署引擎。

Kubernetes 的前身其实是 Google 的 Ball, 在 2013 年开源之后，发展至今。目前已经为开源事件部署引擎的事实标准了。

01

核心概念 Pod

• Pod 由一组容器组成，这些容器共享网络，存储以及相关的声明。    

• Pod 是 Kubernetes 中最小的可部署的计算单元

• 这样的一组容器被“打包”到一起组成了一个 Pod 并接受 Kubernetes 的调度，编排等控制逻辑。

为了让大家更好的理解“一组容器“的概念，接下来为大家详细剖析 Pod 的内部架构。

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）这些容器在创建出来的时候，就都会选择加入到 PauseContainer 创建出来的 net namespace 当中。

当然，也不是所有的 namespace 都是不隔离的。Container 左侧是一个 image，每一个 container 都有一个镜像，每一个镜像又相当于一个容器的 Root ffs。既然每个容器的 Root ffs 是不相同的，那么显而易见，mnt namespace 就是隔离的。

这样我们就可以清楚的看到，什么叫做有些 namespce 在 Pod 当中是互相隔离的，而有些是在 Pod 级别当中共享的。

Pod 在 Kubernetes 中的展现形式

我们先看 Pod 在 Yaml 中的前四行。这四行是资源在 Yaml 中的通用字段。ApiVersion/kind 用于表示 Kubernetes 的资源类型是什么。通过 metadata 来声明资源的源数据。Spec 字段和资源类型是强相关的了。不同的资源会有不同的 spec 定义。那在 Pod 资源当中，最核心的是关于容器的定义了。

下面几行，关于容器的定义，是一个数组类型的，这也符合我们对 Pod 的定义：即它是由一组容器形成的。这些字段包含：声明容器镜像，启动容器的命令，容器镜像的拉取方式，以及容器的名称。

核心概念 Kubelet

Kubelet 是 Kubernetes 集群的“节点代理”。也可以说是 Kubernetes 部署在每个节点的 agent。

Kubelet 启动后会向 Kubernetes 集群注册自己，并上报节点的相关信息。此时在 Kubernetes 集群中就增加了一台新的可用的 Node 节点（可能是一个物理机，也可能是一个虚拟机，甚至是一个容器）。

Kubelet 发现有属于自己节点的 Pod 符合创建条件后，会按照 Pod 声明的配置去启动容器。

下面把这张图分为 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。通过控制器的方式，来完成运行时服务器的编排工作。

02 快速搭建 Kubernetes 集群

搭建工具：Kubeadm 简介

Kubeadm 是 Kubernetes 官方提供的用于快速安装 Kubernetes 集群的工具。

在配置文件当中，我们指定了 dns 的类型，ETCD 存储目录以及要创建的 Kubernetes 的版本以及相关的参数。

搭建环境

初始 Master 节点

Kubeadm init—config kubeadm.conf

安装 flannel cni

https://raw.githusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

03

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

04

总结

本节课作为 K8s 入门系列课程第二节。重点介绍了 Kubernetes 出现的背景和作用、Kubernetes 的特点和核心架构、Kubernetes 每一个模块承担的作用以及实现的功能。并演示了如何搭建一个单节点的 Kubernetes  环境以及如何使用来操作相关的资源。希望对大家有所帮助。

想了解百度更多开放技术，欢迎大家关注“百度开发中心”微信公众号。