Kubernetes 从上手到实践 on GoClub

01 开篇： Kubernetes 是什么以及为什么需要它

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

01 开篇： Kubernetes 是什么以及为什么需要它

Kubernetes 是一个可扩展的，用于容器化应用程序编排，管理的平台。由 Google 于 2014 年基于其大规模生产实践经验而开源出来的。Kubernetes 目前在容器编排领域已经成为事实上的标准，社区也非常活跃。

Kubernetes 在国内外都已经得到广泛的应用，无论是Google, Amazon, GitHub 等还是国内的阿里，腾讯，百度，华为，京东或其他中小公司等也都已全力推进 Kubernetes 在生产中的使用。

现在无论是运维，后端，DBA，亦或者是前端，机器学习工程师等都需要在工作中或多或少的用到 Docker，而在生产中大量使用的话 Kubernetes 也将会成为趋势，所以了解或掌握 Kubernetes 也成为了工程师必不可少的技能之一。

Kubernetes 是什么?

当提到 Kubernetes 的时候，大多数人的可能会想到它可以容器编排，想到它是 PaaS (Platform as a Service) 系统，但其实不然，Kubernetes 并不是 PasS 系统，因为它工作在容器层而不是硬件层，它只不过提供了一些与 PasS 类似或者共同的功能，类似部署，扩容，监控，负载均衡，日志记录等。然而它并不是个完全一体化的平台，这些功能基本都是可选可配置的。

Kubernetes 可支持公有云，私有云及混合云等，具备良好的可移植性。我们可直接使用它或在其之上构建自己的容器/云平台，以达到快速部署，快速扩展，及优化资源使用等。

它致力于提供通用接口类似 CNI( Container Network Interface ), CSI（Container Storage Interface）, CRI（Container Runtime Interface）等规范，以便有更多可能, 让更多的厂商共同加入其生态体系内。它的目标是希望在以后，任何团队都可以在不修改 Kubernetes 核心代码的前提下，可以方便的扩展和构建符合自己需求的平台。

为什么需要 Kubernetes

我们回到实际的工作环境中。

如果你是个前端，你是否遇到过 npm 依赖安装极慢，或是 node sass 安装不了或者版本不对的情况？
如果你是个后端，是否遇到过服务器与本地环境不一致的情况，导致部分功能出现非预期的情况？
如果你是个运维，是否遇到过频繁部署环境，但中间可能出现各种安装不了或者版本不对的问题？

目前来看，对于这些问题，最好的解决方案便是标准化，容器化，现在用到最多的也就是 Docker。 Docker 通过 Dockerfile 来对环境进行描述，通过镜像进行交付，使用时不再需要关注环境不一致相关的问题。

02 初步认识：Kubernetes 基础概念

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

02 初步认识：Kubernetes 基础概念

好了，总算开始进入正题，抛弃掉死板的说教模式，我们以一个虚构的新成立的项目组为例开始我们的 Kubernetes 探索。(以下统一将 Kubernetes 简写为 K8S) 项目组目前就只有一个成员，我们称他为小张。项目组刚成立的时候，小张也没想好，具体要做什么，但肯定要对外提供服务的，所以先向公司申请了一台服务器。

Node

这台服务器可以用来做什么呢？跑服务，跑数据库，跑测试之类的都可以，我们将它所做的事情统称为工作(work) 那么，它便是工作节点 (worker Node) 对应于 K8S 中，这就是我们首先要认识的 Node 。

Node 可以是一台物理机，也可以是虚拟机，对于我们此处的项目来讲，这台服务器便是 K8S 中的 Node 。

Node 状态

当我们拿到这台服务器后，首先我们登录服务器查看下服务器的基本配置和信息。其实对于一个新加入 K8S 集群的 Node 也是一样，需要先检查它的状态，并将状态上报至集群的 master 。我们来看看服务器有哪些信息是我们所关心的。

地址

首先，我们所关心的是我们服务器的 IP 地址，包括内网 IP 和外网 IP。对应于 K8S 集群的话这个概念是类似的，内部 IP 可在 K8S 集群内访问，外部 IP 可在集群外访问。

其次，我们也会关心一下我们的主机名，比如在服务器上执行 hostname 命令，便可得到主机名。K8S 集群中，每个 Node 的主机名也会被记录下来。当然，我们可以通过给 Kubelet 传递一个 –hostname-override 的参数来覆盖默认的主机名。 (Kubelet 是什么，我们后面会解释)

信息

再之后，我们需要看下服务器的基本信息，比如看看系统版本信息， cat /etc/issue 或者 cat /etc/os-release 等方法均可查看。对于 K8S 集群会将每个 Node 的这些基础信息都记录下来。

03 宏观认识：整体架构

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

03 宏观认识：整体架构

工欲善其事，必先利其器。本节我们来从宏观上认识下 K8S 的整体架构，以便于后续在此基础上进行探索和实践。

C/S 架构

从更高层来看，K8S 整体上遵循 C/S 架构，从这个角度来看，可用下面的图来表示其结构：

左侧是一个官方提供的名为 kubectl 的 CLI （Command Line Interface）工具，用于使用 K8S 开放的 API 来管理集群和操作对象等。

右侧则是 K8S 集群的后端服务及开放出的 API 等。根据上一节的内容，我们知道 Node 是用于工作的机器，而 Master 是一种角色（Role），表示在这个 Node 上包含着管理集群的一些必要组件。具体组件的详细介绍参考第 11 小节对各组件的详细剖析。

当然在这里，只画出了一个 Master，在生产环境中，为了保障集群的高可用，我们通常会部署多个 Master 。

Master

下面我们来逐层分解，首先是 Master ，这里我们只介绍其管理集群的相关组件。Master 是整个 K8S 集群的“大脑”，与大脑类似，它有几个重要的功能：

接收：外部的请求和集群内部的通知反馈
发布：对集群整体的调度和管理
存储：存储

这些功能，也通过一些组件来共同完成，通常情况下，我们将其称为 control plane 。如下图所示：

它主要包含以下几个重要的组成部分。

Cluster state store

存储集群所有需持久化的状态，并且提供 watch 的功能支持，可以快速的通知各组件的变更等操作。

因为目前 Kubernetes 的存储层选择是 etcd ，所以一般情况下，大家都直接以 etcd 来代表集群状态存储服务。即：将所有状态存储到 etcd 实例中。

04 搭建 Kubernetes 集群 - 本地快速搭建

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

04 搭建 Kubernetes 集群 - 本地快速搭建

通过之前的学习，我们已经知道了 K8S 中有一些组件是必须的，集群中有不同的角色。本节，我们在本地快速搭建一个集群，以加深我们学习到的东西。

方案选择

在上一节中，我们知道 K8S 中有多种功能组件，而这些组件要在本地全部搭建好，需要一些基础知识，以及在搭建过程中会浪费不少的时间，从而可能会影响我们正常的搭建集群的目标。

所以，我们这里提供两个最简单，最容易实现我们目标的工具

KIND 。
Minikube 。

KIND

介绍

KIND（Kubernetes in Docker）是为了能提供更加简单，高效的方式来启动 K8S 集群，目前主要用于比如 Kubernetes 自身的 CI 环境中。

安装

可以直接在项目的 Release 页面下载已经编译好的二进制文件。(下文中使用的是 v0.1.0 版本的二进制包)

注意：如果不直接使用二进制包，而是使用 go get sigs.k8s.io/kind 的方式下载，则与下文中的配置文件不兼容。请参考使用 Kind 搭建你的本地 Kubernetes 集群 这篇文章。

更新（2020年2月5日）：KIND 已经发布了 v0.7.0 版本，如果你想使用新版本，建议参考使用 Kind 在离线环境创建 K8S 集群，这篇文章使用了最新版本的 KIND。

创建集群

在使用 KIND 之前，你需要本地先安装好 Docker 的环境 ，此处暂不做展开。

05 动手实践：搭建一个 Kubernetes 集群 - 生产可用

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

05 动手实践：搭建一个 Kubernetes 集群 - 生产可用

通过上一节的学习，我们快速的使用 Minikube 搭建了一个本地可用的 K8S 集群。默认情况下，节点是一个虚拟机实例，我们可以在上面体验一些基本的功能。

大多数人的需求并不只是包含一个虚拟机节点的本地测试集群，而是一个可在服务器运行，可自行扩/缩容，具备全部功能的，达到生产可用的集群。

K8S 集群的搭建，一直让很多人头疼，本节我们来搭建一个生产可用的集群，便于后续的学习或使用。

方案选择

K8S 生产环境可用的集群方案有很多，本节我们选择一个 Kubernetes 官方推荐的方案 kubeadm 进行搭建。

kubeadm 是 Kubernetes 官方提供的一个 CLI 工具，可以很方便的搭建一套符合官方最佳实践的最小化可用集群。当我们使用 kubeadm 搭建集群时，集群可以通过 K8S 的一致性测试，并且 kubeadm 还支持其他的集群生命周期功能，比如升级/降级等。

我们在此处选择 kubeadm ，因为我们可以不用过于关注集群的内部细节，便可以快速的搭建出生产可用的集群。我们可以通过后续章节的学习，快速上手 K8S ，并学习到 K8S 的内部原理。在此基础上，想要在物理机上完全一步步搭建集群，便轻而易举。

安装基础组件

前期准备

使用 kubeadm 前，我们需要提前做一些准备。

我们需要禁用 swap。通过之前的学习，我们知道每个节点上都有个必须的组件，名为 kubelet，自 K8S 1.8 开始，启动 kubelet 时，需要禁用 swap 。或者需要更改 kubelet 的启动参数 –fail-swap-on=false。

虽说可以更改参数让其可用，但是我建议还是禁用 swap 除非你的集群有特殊的需求，比如：有大内存使用的需求，但又想节约成本；或者你知道你将要做什么，否则可能会出现一些非预期的情况，尤其是做了内存限制的时候，当某个 Pod 达到内存限制的时候，它可能会溢出到 swap 中，这会导致 K8S 无法正常进行调度。

如何禁用：

06 集群管理：初识 kubectl

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

06 集群管理：初识 kubectl

从本节开始，我们来学习 K8S 集群管理相关的知识。通过前面的学习，我们知道 K8S 遵循 C/S 架构，官方也提供了 CLI 工具 kubectl 用于完成大多数集群管理相关的功能。当然凡是你可以通过 kubectl 完成的与集群交互的功能，都可以直接通过 API 完成。

对于我们来说 kubectl 并不陌生，在第 3 章讲 K8S 整体架构时，我们首次提到了它。在第 4 章和第 5 章介绍了两种安装 kubectl 的方式故而本章不再赘述安装的部分。

整体概览

首先我们在终端下执行下 kubectl:

kubectl 已经将命令做了基本的归类，同时显示了其一般的用法 kubectl [flags] [options] 。

使用 kubectl options 可以看到所有全局可用的配置项。

基础配置

在我们的用户家目录，可以看到一个名为 .kube/config 的配置文件，我们来看下其中的内容（此处以本地的 minikube 集群为例）。

$HOME/.kube/config 中主要包含着：

K8S 集群的 API 地址
用于认证的证书地址

当然，我们在第 5 章时，也已经说过，也可以使用 –kubeconfig 或者环境变量 KUBECONFIG 来传递配置文件。

另外如果你并不想使用配置文件的话，你也可以通过使用直接传递相关参数来使用，例如：

从 get 说起

无论是第 4 章还是第 5 章，当我们创建集群后，我们都做了两个相同的事情，一个是执行 kubectl get nodes 另一个则是 kubectl cluster-info，我们先从查看集群内 Node 开始。

07 集群管理：以 Redis 为例-部署及访问

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

07 集群管理：以 Redis 为例-部署及访问

上节我们已经学习了 kubectl 的基础使用，本节我们使用 kubectl 在 K8S 中进行部署。

前面我们已经说过，Pod 是 K8S 中最小的调度单元，所以我们无法直接在 K8S 中运行一个 container 但是我们可以运行一个 Pod 而这个 Pod 中只包含一个 container 。

从 kubectl run 开始

kubectl run 的基础用法如下：

NAME 和 –image 是必需项。分别代表此次部署的名字及所使用的镜像，其余部分之后进行解释。当然，在我们实际使用时，推荐编写配置文件并通过 kubectl create 进行部署。

使用最小的 Redis 镜像

在 Redis 的官方镜像列表可以看到有很多的 tag 可供选择，其中使用 Alpine Linux 作为基础的镜像体积最小，下载较为方便。我们选择 redis:alpine 这个镜像进行部署。

部署

现在我们只部署一个 Redis 实例。

可以看到提示 deployment.apps/redis created 这个稍后进行解释，我们使用 kubectl get all 来看看到底发生了什么。

可以看到其中有我们刚才执行 run 操作后创建的 deployment.apps/redis，还有 replicaset.apps/redis-7c7545cbcb, service/kubernetes 以及 pod/redis-7c7545cbcb-f984p。

08 安全重点认证和授权

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

08 安全重点认证和授权

本节我们将开始学习将 K8S 应用于生产环境中至关重要的一环，权限控制。当然，不仅是 K8S 对于任何应用于生产环境中的系统，权限管理或者说访问控制都是很重要的。

整体概览

通过前面的学习，我们已经知道 K8S 中几乎所有的操作都需要经过 kube-apiserver 处理，所以为了安全起见，K8S 为它提供了三类安全访问的措施。分别是：用于识别用户身份的认证（Authentication），用于控制用户对资源访问的授权（Authorization）以及用于资源管理方面的准入控制（Admission Control）。

下面的图基本展示了这一过程。来自客户端的请求分别经过认证，授权，准入控制之后，才能真正执行。

当然，这里说基本展示是因为我们可以直接通过 kubectl proxy 的方式直接通过 HTTP 请求访问 kube-apiserver 而无需任何认证过程。

另外，也可通过在 kube-apiserver 所启动的机器上，直接访问启动时 –insecure-port 参数配置的端口进行绕过认证和授权，默认是 8080。为了避免安全问题，也可将此参数设置为 0 以规避问题。注意：这个参数和 –insecure-bind-address 都已过期，并将在未来的版本移除。

认证（Authentication）

认证，无非是判断当前发起请求的用户身份是否正确。例如，我们通常登录服务器时候需要输入用户名和密码，或者 SSH Keys 之类的。

在讲认证前，我们应该先理一下 K8S 中的用户。

K8S 中有两类用户，一般用户及 Service Account。

一般用户：一般用户只能通过外部服务进行管理，由管理员进行私钥分发。这也意味着 K8S 中并没有任何表示一般用户的对象，所以一般用户是无法通过 API 直接添加到集群的。
Service Account：由 K8S API 管理的用户，与特定的 NameSpace（命名空间）绑定。由 API Server 自动创建或者通过 API 手动进行创建。同时，它会自动挂载到 Pod 中容器的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中，其中会包含 NameSpace token 等信息，并允许集群内进程与 API Server 进行交互。

对集群操作的 API 都是与用户相关联的，或者被视为匿名请求。匿名请求可通过 kube-apiserver 的 –anonymous-auth 参数进行控制，默认是开启的，匿名用户默认的用户名为 system:anonymous，所属组为 system:unauthenticated。

09 应用发布：部署实际项目

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

09 应用发布：部署实际项目

本节我们开始学习如何将实际项目部署至 K8S 中，开启生产实践之路。

整体概览

本节所用示例项目是一个混合了 Go，NodeJS，Python 等语言的项目，灵感来自于知名程序员 Kenneth Reitz 的 Say Thanks 项目。本项目实现的功能主要有两个：1. 用户通过前端发送感谢消息 2. 有个工作进程会持续的计算收到感谢消息的排行榜。项目代码可在 GitHub 上获得。接下来几节中如果需要用到此项目我会统一称之为 saythx 项目。

saythx 项目的基础结构如下图：

构建镜像

前端

我们使用了前端框架 Vue，所以在做生产部署时，需要先在 Node JS 的环境下进行打包构建。包管理器使用的是 Yarn。然后使用 Nginx 提供服务，并进行反向代理，将请求正确的代理至后端。

Nginx 的配置文件如下：

将 API 的请求反向代理到后端服务上。其余请求全部留给前端进行处理。

后端

后端是使用 Golang 编写的 API 服务，对请求进行相应处理，并将数据存储至 Redis 当中。依赖管理使用的是 dep。由于 Golang 是编译型语言，编译完成后会生成一个二进制文件，为了让镜像尽可能小，所以 Dockerfile 和前端的差不多，都使用了多阶段构建的特性。

注意这里会暴露出来后端服务所监听的端口。

Work

Work 端使用的是 Python，用于计算已经存储至 Redis 当中的数据，并生成排行榜。依赖使用 pip 进行安装。对于 Python 的镜像选择，我做了一组性能对比的测试有兴趣可以了解下。

10 应用管理：初识 Helm

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

10 应用管理：初识 Helm

整体概览

上节，我们已经学习了如何通过编写配置文件的方式部署项目。而在实际生产环境中，项目所包含组件可能不止 3 个，并且可能项目数会很多，如果每个项目的发布，更新等都通过手动去编写配置文件的方式，实在不利于管理。

并且，当线上出现个别组件升级回滚之类的操作，如果组件之间有相关版本依赖等情况，那事情会变得复杂的多。我们需要有更简单的机制来辅助我们完成这些事情。

Helm 介绍

Helm 是构建于 K8S 之上的包管理器，可与我们平时接触到的 Yum，APT，Homebrew 或者 Pip 等包管理器相类比。

使用 Helm 可简化包分发，安装，版本管理等操作流程。同时它也是 CNCF 孵化项目。

Helm 安装

Helm 是 C/S 架构，主要分为客户端 helm 和服务端 Tiller。安装时可直接在 Helm 仓库的 Release 页面下载所需二进制文件或者源码包。

由于当前项目的二进制文件存储已切换为 GCS，我已经为国内用户准备了最新版本的二进制包，可通过以下链接进行下载。

下载后对文件进行解压，我这里以 Linux amd64 为例。

解压完成后，可看到其中包含 helm 和 tiller 二进制文件。

客户端 helm

helm 是个二进制文件，直接将它移动至 /usr/bin 目录下即可。

这时候便可直接通过 helm 命令使用了。比如，我们验证当前使用的版本。

可以看到上面有明显的报错，并且很像 kubectl 未正确配置时的错误。这是因为 helm 默认会去读取 $HOME/.kube/config 的配置文件，用于正确的连接至目标集群。

当我们正确的配置好 $HOME/.kube/config 文件时，再次执行：

11 部署实践：以 Helm 部署项目

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

11 部署实践：以 Helm 部署项目

概览

上节，我们学习到了 Helm 的基础概念和工作原理，本节我们将 Helm 用于我们的实际项目，编写 Helm chart 以及通过 Helm 进行部署。

Helm chart

上节我们解释过 chart 的含义，现在我们要将项目使用 Helm 部署，那么首先，我们需要创建一个 chart。

Chart 结构

在我们项目的根目录下，通过以下命令创建一个 chart。

创建完成后，我们可以看到默认创建的 chart 中包含了几个文件和目录。我们先对其进行解释。

Chart.yaml

这个文件是每个 chart 必不可少的一个文件，其中包含着几个重要的属性，如：

apiVersion：目前版本都为 v1
appVersion：这是应用的版本号，需要与 apiVersion， version 等字段注意区分
name: 通常要求 chart 的名字必须和它所在目录保持一致，且此字段必须
version：表明当前 chart 的版本号，会直接影响 Release 的记录，且此字段必须
description：描述

charts

charts 文件夹是用于存放依赖的 chart 的。当有依赖需要管理时，可添加 requirements.yaml 文件，可用于管理项目内或者外部的依赖。

.helmignore

.helmignore 类似于 .gitignore 和 .dockerignore 之类的，用于忽略掉一些不想包含在 chart 内的文件。

templates

templates 文件夹内存放着 chart 所使用的模板文件，也是 chart 的实际执行内容。在使用 chart 进行安装的时候，会将下面介绍的 values.yaml 中的配置项与 templates 中的模板进行组装，生成最终要执行的配置文件。

12 庖丁解牛：kube-apiserver

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

12 庖丁解牛：kube-apiserver

整体概览

在第 3 节《宏观认识：整体架构》中，我们初次认识到了 kube-apiserver 的存在（以下内容中将统一称之为 kube-apiserver），知道了它作为集群的统一入口，接收来自外部的信号和请求，并将一些信息存储至 etcd 中。

但这只是一种很模糊的说法，本节我们来具体看看 kube-apiserver 的关键功能以及它的工作原理。

注意：本节所有的源码均以 v1.11.3 为准 commit id a4529464e4629c21224b3d52edfe0ea91b072862。

REST API Server

先来说下 kube-apiserver 作为整个集群的入口，接受外部的信号和请求所应该具备的基本功能。

首先，它对外提供接口，可处理来自客户端（无论我们在用的 kubeclt 或者 curl 或者其他语言实现的客户端）的请求，并作出响应。

在第 5 节搭建集群时，我们提到要先去检查 6443 端口是否被占用。这样检查的原因在于 kube-apiserver 有个 –secure-port 的参数，通过这个参数来配置它将要监听在哪个端口，默认情况下是 6443。

当然，它还有另一个参数 –insecure-port ，这个参数可将 kube-apiserver 绑定到其指定的端口上，且通过该端口访问时无需认证。

在生产环境中，建议将其设置为 0 以禁用该功能。另外，这个参数也已经被标记为废弃，将在之后版本中移除。如果未禁用该功能，建议通过防火墙策略禁止从外部访问该端口。该端口会绑定在 –insecure-bind-address 参数所设置的地址上，默认为 127.0.0.1。

那么 secure 和 insecure 最主要的区别是什么呢？这就引出来了 kube-apiserver 作为 API Server 的一个最主要功能：认证。

认证（Authentication）

在第 8 节《认证和授权》中，我们已经讲过认证相关的机制。这里，我们以最简单的获取集群版本号为例。

13 庖丁解牛：etcd

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

13 庖丁解牛：etcd

整体概览

在第 3 节《宏观认识：整体架构》中，我们也认识到了 etcd 的存在，知道了 Master 是 K8S 是集群的大脑，而 etcd 则是大脑的核心。为什么这么说？本节我们一同来看看 etcd 为何如此重要。

etcd 是什么

先摘录官方文档的一句说明:

etcd 是由 CoreOS 团队发起的一个分布式，强一致的键值存储。它用 Go 语言编写，使用 Raft 协议作为一致性算法。多数情况下会用于分布式系统中的服务注册发现，或是用于存储系统的关键数据。

etcd 有什么作用

etcd 在 K8S 中，最主要的作用便是其高可用，强一致的键值存储以及监听机制。

在 kube-apiserver 收到对应请求经过一系列的处理后，最终如果是集群所需要存储的数据，便会存储至 etcd 中。主部分主要是集群状态信息和元信息。

我们来实际操作 K8S 集群中的 etcd 看下真实情况。

查找集群中的 etcd Pod

进入该 Pod 并查看 etcd 集群的 member

这里由于在 K8S 1.11.3 中默认使用的是 etcd 3.2 版本，所以需要加入 ETCDCTL_API=3 的环境变量，且 etcd 从 2 到 3 很明显的一个变化也是使用上的变化，在 2 中是 HTTP 接口的。

14 庖丁解牛：controller-manager

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

14 庖丁解牛：controller-manager

整体概览

在第 3 节《宏观认识：整体架构》中，我们也认识到了 Controller Manager 的存在，知道了 Master 是 K8S 是集群的大脑，而它则是 Master 中最繁忙的部分。为什么这么说？本节我们一同来看看它为何如此繁忙。

注意：Controller Manager 实际由 kube-controller-manager 和 cloud-controller-manager 两部分组成，cloud-controller-manager 则是为各家云厂商提供了一个抽象的封装，便于让各厂商使用各自的 provide。本文只讨论 kube-controller-manager，为了避免混淆，下文统一使用 kube-controller-manager。

kube-controller-manager 是什么

一句话来讲 kube-controller-manager 是一个嵌入了 K8S 核心控制循环的守护进程。

这里的重点是

嵌入：它已经内置了相关逻辑，可独立进行部署。我们在第 5 节下载 K8S 服务端二进制文件解压后，便可以看到 kube-controller-manager 的可执行文件，不过我们使用的是 kubeadm 进行的部署，它会默认使用 k8s.gcr.io/kube-controller-manager 的镜像。我们直接来看下实际情况：

这是使用 kubeadm 搭建的集群中的 kube-controller-manager 的 Pod，首先可以看到它所使用的镜像，其次可以看到它使用的一系列参数，最后它在 10252 端口提供了健康检查的接口。稍后我们再展开。

控制循环：这里拆解为两部分：控制和循环，它所控制的是集群的状态；至于循环它当然是会有个循环间隔的，这里有个参数可以进行控制。
守护进程：这个就不单独展开了。

kube-controller-manager 有什么作用

前面已经说了它一个很关键的点 “控制”：它通过 kube-apiserver 提供的信息持续的监控集群状态，并尝试将集群调整至预期的状态。由于访问 kube-apiserver 也需要通过认证，授权等过程，所以可以看到上面启动 kube-controller-manager 时提供了一系列的参数。

15 庖丁解牛：kube-scheduler

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

15 庖丁解牛：kube-scheduler

整体概览

在第 3 节《宏观认识：整体架构》中，我们也认识到了 Scheduler 的存在，知道了 Master 是 K8S 是集群的大脑，Controller Manager 负责将集群调整至预期的状态，而 Scheduler 则是集群调度器，将预期的 Pod 资源调度到正确的 Node 节点上，进而令该 Pod 可完成启动。本节我们一同来看看它如何发挥如此大的作用。

下文统一使用 kube-scheduler 进行表述

kube-scheduler 是什么

引用官方文档一句话：

kube-scheduler 是一个策略丰富，拓扑感知的调度程序，会显著影响可用性，性能和容量。

我们知道资源调度本就是 K8S 这类系统中的一个很复杂的事情，既要能满足系统对资源利用率的需要，同样还需要避免资源竞争，比如说端口冲突之类的。

为了能完成这样的需求，kube-scheduler 便在不断的迭代和发展，通过支持多种策略满足各类需求，通过感知拓扑避免资源竞争和保障系统的可用性及容量等。

我们在第 5 节下载服务端二进制文件解压后，便可看到 kube-scheduler 的可执行文件。当给它传递 –help 查看其支持参数的时候，便可以看到它支持使用 –address 或者 –bind-address 等参数指定所启动的 HTTP server 所绑定的地址之类的。

它和 kube-controller-manager 有点类似，同样是通过定时的向 kube-apiserver 请求获取信息，并进行处理。而他们所起到的作用并不相同。

kube-scheduler 有什么作用

从上层的角度来看，kube-scheduler 的作用就是将待调度的 Pod 调度至最佳的 Node 上，而这个过程中则需要根据不同的策略，考虑到 Node 的资源使用情况，比如端口，内存，存储等。

kube-scheduler 是如何工作的

整体的过程可通过 pkg/scheduler/core/generic_scheduler.go 的代码来看

16 庖丁解牛：kubelet

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

16 庖丁解牛：kubelet

整体概览

在第 3 节《宏观认识：整体架构》中，我们知道了 K8S 中 Node 由一些必要的组件构成，而其中最为核心的当属 kubelet 了，如果没有 kubelet 的存在，那我们预期的各类资源就只能存在于 Master 的相关组件中了，而 K8S 也很能只是一个 CRUD 的普通程序了。本节，我们来介绍下 kubelet 及它是如何完成这一系列任务的。

kubelet 是什么

按照一般架构设计上的习惯，kubelet 所承担的角色一般会被叫做 agent，这里叫做 kubelet 很大程度上受 Borg 的命名影响，Borg 里面也有一个 Borglet 的组件存在。kubelet 便是 K8S 中的 agent，负责 Node 和 Pod 相关的管理任务。

同样的，在我们下载 K8S 二进制文件解压后，便可以得到 kubelet 的可执行文件。在第 5 节中，我们也完成了 kubelet 以 systemd 进行启动和管理的相关配置。

kubelet 有什么作用

通常来讲 agent 这样的角色起到的作用首先便是要能够注册，让 server 端知道它的存在，所以这便是它的第一个作用：节点管理。

节点管理

当我们执行 kubelet –help 的时候，会看到它所支持的可配置参数，其中有一个 –register-node 参数便是用于控制是否向 kube-apiserver 注册节点的，默认是开启的。

17 庖丁解牛：kube-proxy

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

17 庖丁解牛：kube-proxy

整体概览

在第 3 节中，我们了解到 kube-proxy 的存在，而在第 7 中，我们学习到了如何将运行于 K8S 中的服务以 Service 的方式暴露出来，以供访问。

本节，我们来介绍下 kube-proxy 了解下它是如何支撑起这种类似服务发现和代理相关功能的。

kube-proxy 是什么

kube-proxy 是 K8S 运行于每个 Node 上的网络代理组件，提供了 TCP 和 UDP 的连接转发支持。

我们已经知道，当 Pod 在创建和销毁的过程中，IP 可能会发生变化，而这就容易造成对其有依赖的服务的异常，所以通常情况下，我们都会使用 Service 将后端 Pod 暴露出来，而 Service 则较为稳定。

还是以我们之前的 SayThx 项目为例，但我们只部署其中没有任何依赖的后端资源 Redis 。

进入配置文件所在目录后，开始创建相关资源：

可以看到 Redis 正在运行，并通过 NodePort 类型的 Service 暴露出来，我们访问来确认下。

可以看到已经可以正常访问。接下来，我们来看下 31269 这个端口的状态。

可以看到该端口是由 kube-proxy 所占用的。

接下来，查看当前集群的 Service 和 Endpoint

可以很直观的看到 Endpoint 当中的便是 Pod 的 IP，现在我们将该服务进行扩容（实际情况下并不会这样处理）。

18 庖丁解牛：Container Runtime （Docker）

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

18 庖丁解牛：Container Runtime （Docker）

整体概览

我们在第 3 节的时候，提到过 Container Runtime 的概念，也大致介绍过它的主要作用在于下载镜像，运行容器等。

经过我们前面的学习，kube-scheduler 决定了 Pod 将被调度到哪个 Node 上，而 kubelet 则负责 Pod 在此 Node 上可按预期工作。如果没有 Container Runtime，那 Pod 中的 container 在该 Node 上也便无法正常启动运行了。

本节中，我们以当前最为通用的 Container Runtime Docker 为例进行介绍。

Container Runtime 是什么

Container Runtime 我们通常叫它容器运行时，而这一概念的产生也是由于容器化技术和 K8S 的大力发展，为了统一工业标准，也为了避免 K8S 绑定于特定的容器运行时，所以便成立了 Open Container Initiative (OCI) 组织，致力于将容器运行时标准化和容器镜像标准化。

凡是遵守此标准的实现，均可由标准格式的镜像启动相应的容器，并完成一些特定的操作。

Docker 是什么

Docker 是一个容器管理平台，它最初是被设计用于快速创建，发布和运行容器的工具，不过随着它的发展，其中集成了越来越多的功能。

Docker 也可以说是一个包含标准容器运行时的工具集，当前版本中默认的 runtime 称之为 runc。关于 runc 相关的一些内容可参考我之前的一篇文章。

当然，这里提到了 默认的运行时 那也就意味着它可支持其他的运行时实现。

19 Troubleshoot

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

19 Troubleshoot

整体概览

通过前面的介绍，我们已经了解到了 K8S 的基础知识，核心组件原理以及如何在 K8S 中部署服务及管理服务等。

但在生产环境中，我们所面临的环境多种多样，可能会遇到各种问题。本节将结合我们已经了解到的知识，介绍一些常见问题定位和解决的思路或方法，以便大家在生产中使用 K8S 能如鱼得水。

应用部署问题

首先我们从应用部署相关的问题来入手。这里仍然使用我们的示例项目 SayThx。

clone 该项目，进入到 deploy 目录中，先 kubectl apply -f namespace.yaml 或者 kubectl create ns work 来创建一个用于实验的 Namespace 。

使用 describe 排查问题

对 redis-deployment.yaml 稍作修改，按以下方式操作：

可以看到 Pod 此刻的状态是 ImagePullBackOff，这个状态表示镜像拉取失败，kubelet 退出镜像拉取。

我们在前面的内容中介绍过 kubelet 的作用之一就是负责镜像拉取，而实际上，在镜像方面的错误主要预设了 6 种，分别是 ImagePullBackOff，ImageInspectError，ErrImagePull，ErrImageNeverPull，RegistryUnavailable，InvalidImageName。

当遇到以上所述情况时，便可定位为镜像相关异常。

我们回到上面的问题当中，定位问题所在。

可以看到我们现在 pull 的镜像是 redis:5xx 而实际上并不存在此 tag 的镜像，所以导致拉取失败。

使用 events 排查问题

当然，我们还有另一种方式同样可进行问题排查：

我们在之前介绍时，也提到过 kubelet 或者 kube-scheduler 等组件会接受某些事件等，event 便是用于记录集群内各处发生的事件之类的。

修正错误

修正配置文件

修正配置文件，然后 kubectl apply -f redis-deployment.yaml 便可应用修正后的配置文件。这种方法比较推荐，并且可以将修改过的位置纳入到版本控制系统中，有利于后续维护。

20 扩展增强：Dashboard

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

20 扩展增强：Dashboard

整体概览

通过前面的介绍，想必你已经迫不及待的想要将应用部署至 K8S 中，但总是使用 kubectl 或者 Helm 等命令行工具也许不太直观，你可能想要一眼就看到集群当前的状态，或者想要更方便的对集群进行管理。

本节将介绍一个 Web 项目 Dashboard 可用于部署容器化的应用程序，管理集群中的资源，甚至是排查和解决问题。

当然它和大多数 Dashboard 类的项目类似，也为集群的状态提供了一个很直观的展示。

如何安装

要想使用 Dashboard，首先我们需要安装它，而 Dashboard 的安装其实也很简单。不过对于国内用户需要注意的是需要解决网络问题，或替换镜像地址等。

这里我们安装当前最新版 v1.10.1 的 Dashboard：

对于已经解决网络问题的用户：

可使用官方推荐做法进行安装，以下链接是使用了我提交了 path 的版本，由于官方最近的一次更新导致配置文件中的镜像搞错了。

也可使用我修改过的这份（使用 Docker Hub 同步了镜像）仓库地址 GitHub, 国内 Gitee：

当已经执行完以上步骤后，可检查下是否安装成功：

可以看到 Pod 已经在正常运行，接下来便是访问 Dashboard.

访问 Dashboard

以当前的部署方式，Service 使用了 ClusterIP 的类型，所以在集群外不能直接访问。我们先使用 kubectl 提供的 port-forward 功能进行访问。

还记得，我们在第 5 节时候安装过一个名为 socat 的依赖项吗？ socat 的主要功能便是端口转发。

现在在浏览器打开 https://127.0.0.1:8443 便可看到如下的登录界面。

21 扩展增强：CoreDNS

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

21 扩展增强：CoreDNS

整体概览

通过前面的学习，我们知道在 K8S 中有一套默认的集群内 DNS 服务，我们通常把它叫做 kube-dns，它基于 SkyDNS，为我们在服务注册发现方面提供了很大的便利。

比如，在我们的示例项目 SayThx 中，各组件便是依赖 DNS 进行彼此间的调用。

本节，我们将介绍的 CoreDNS 是 CNCF 旗下又一孵化项目，在 K8S 1.9 版本中加入并进入 Alpha 阶段。我们当前是以 K8S 1.11 的版本进行介绍，它并不是默认的 DNS 服务，但是它作为 K8S 的 DNS 插件的功能已经 GA 。

CoreDNS 在 K8S 1.13 版本中才正式成为默认的 DNS 服务。

CoreDNS 是什么

首先，我们需要明确 CoreDNS 是一个独立项目，它不仅可支持在 K8S 中使用，你也可以在你任何需要 DNS 服务的时候使用它。

CoreDNS 使用 Go 语言实现，部署非常方便。

它的扩展性很强，很多功能特性都是通过插件完成的，它不仅有大量的内置插件，同时也有很丰富的第三方插件。甚至你自己写一个插件也非常的容易。

22 服务增强：Ingress

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

22 服务增强：Ingress

整体概览

通过前面的学习，我们已经知道 K8S 中有 Service 的概念，同时默认情况下还有 CoreDNS 完成集群内部的域名解析等工作，以此完成基础的服务注册发现能力。

在第 7 节中，我们介绍了 Service 的 4 种基础类型，在前面的介绍中，我们一般都在使用 ClusterIP 或 NodePort 等方式将服务暴露在集群内或者集群外。

本节，我们将介绍另一种处理服务访问的方式 Ingress。

Ingress 是什么

通过 kubectl explain ingress 命令，我们来看下对 Ingress 的描述。

Ingress 是一组允许外部请求进入集群的路由规则的集合。它可以给 Service 提供集群外部访问的 URL，负载均衡，SSL 终止等。

直白点说，Ingress 就类似起到了智能路由的角色，外部流量到达 Ingress ，再由它按已经制定好的规则分发到不同的后端服务中去。

看起来它很像我们使用的负载均衡器之类的。那你可能会问，Ingress 与 LoadBalancer 类型的 Service 的区别是什么呢？

Ingress 不是一种 Service 类型

Ingress 是 K8S 中的一种资源类型，我们可以直接通过 kubectl get ingress 的方式获取我们已有的 Ingress 资源。

Ingress 可以有多种控制器（实现）

通过之前的介绍，我们知道 K8S 中有很多的 Controller (控制器)，而这些 Controller 已经打包进了 kube-controller-manager 中，通过 –controllers 参数控制启用哪些。

23 监控实践：对 K8S 集群进行监控

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

23 监控实践：对 K8S 集群进行监控

整体概览

通过前面的学习，我们对 K8S 有了一定的了解，也具备了一定的集群管理和排错能力。但如果要应用于生产环境中，不可能随时随地的都盯着集群，我们需要扩展我们对集群的感知能力。

本节，我们将介绍下 K8S 集群监控相关的内容。

监控什么

除去 K8S 外，我们平时自己开发的系统或者负责的项目，一般都是有监控的。监控可以提升我们的感知能力，便于我们及时了解集群的变化，以及知道哪里出现了问题。

K8S 是一个典型的分布式系统，组件很多，那么监控的目标，就变的很重要了。

总体来讲，对 K8S 集群的监控的话，主要有以下方面：

节点情况
K8S 集群自身状态
部署在 K8S 内的应用的状态

Prometheus

对于 K8S 的监控，我们选择 CNCF 旗下次于 K8S 毕业的项目 Prometheus 。

Prometheus 是一个非常灵活易于扩展的监控系统，它通过各种 exporter 暴露数据，并由 prometheus server 定时去拉数据，然后存储。

它自己提供了一个简单的前端界面，可在其中使用 PromQL 的语法进行查询，并进行图形化展示。

安装 Prometheus

我们此处选择以一般的方式进行部署，带你了解其整体的过程。

创建一个独立的 Namespace：

RBAC

我们的集群使用 kubeadm 创建，默认开启了 RBAC，所以现在需要创建相关的 Role 和 binding。

执行创建

创建 Promethes 的配置文件

其中的内容主要参考 Prometheus 官方提供的示例和 Prometheus 官方文档。

24 总结

Mon, 01 Jan 0001 00:00:00 +0000

来源：技术书栈原文。本页按授权迁移至 GoClub。

24 总结

快速回顾

经过了前面 23 节的内容，我们从 K8S 的基础概念入手，通过其基础架构了解到了 K8S 中所涉及到的各类组件。

通过动手实践，使用 minikube 搭建了本地的集群，使用 kubeadm 完成了服务器上的集群搭建，对 K8S 的部署有了更加清晰的认识。

这里再推荐另一种正在快速迭代的方式 Kubernetes In Docker 可以很方便的创建廉价的 K8S 集群，目前至支持单节点集群，多节点支持正在开发中。

后面，我们通过学习 kubectl 的使用，部署了 Redis 服务，了解到了一个服务在 K8S 中部署的操作，以及如何将服务暴露至集群外，以便访问。

当集群真正要被使用之前，权限管控也愈发重要，我们通过学习 RBAC 的相关知识，学习到了如何在 K8S 集群中创建权限可控的用户，而这部分的内容在后续小节中也被频繁用到。

接下来，我们以我们实际的一个项目 SayThx 为例，一步步的完成了项目的部署，在此过程中也学习到了配置文件的编写规范和要求。

当项目变大时，维护项目的更新也变成了一件很麻烦的事情。由此，我们引入了 Helm 作为我们的包管理软件，并使用它进行了项目的部署。

在此过程中也学习到了 Helm 的架构，以及如何编写一个 Chart 等知识。

前面我们主要集中于如何使用 K8S 上，接下了庖丁解牛系列便带我们一同深入至 K8S 内部，了解到了各基础组件的实际工作原理，也深入到了源码内部，了解其实现逻辑。

有这些理论知识作为基础，我们便可以大胆的将应用部署至 K8S 之上了。但实际环境可能多种多样，你可以会遇到各种各样的问题。

这里我们介绍了一些常见的 Troubleshoot 的方法，以便你在后续使用 K8S 的过程中遇到问题也可以快速的定位并解决问题。

此外，我们学习了 K8S 的一些扩展，比如 Dashboard 和 CoreDNS ， Dashboard 是一个比较直观的管理资源的方式，它也还在快速的发展和迭代中。

Kubernetes 从上手到实践 on GoClub

01 开篇： Kubernetes 是什么以及为什么需要它

01 开篇： Kubernetes 是什么以及为什么需要它

Kubernetes 是什么?

为什么需要 Kubernetes

02 初步认识：Kubernetes 基础概念

02 初步认识：Kubernetes 基础概念

Node

Node 状态

地址

信息

03 宏观认识：整体架构

03 宏观认识：整体架构

C/S 架构

Master

Cluster state store

04 搭建 Kubernetes 集群 - 本地快速搭建

04 搭建 Kubernetes 集群 - 本地快速搭建

方案选择

KIND

介绍

安装

创建集群

05 动手实践：搭建一个 Kubernetes 集群 - 生产可用

05 动手实践：搭建一个 Kubernetes 集群 - 生产可用

方案选择

安装基础组件

前期准备

06 集群管理：初识 kubectl

06 集群管理：初识 kubectl

整体概览

基础配置

从 get 说起

07 集群管理：以 Redis 为例-部署及访问

07 集群管理：以 Redis 为例-部署及访问

从 kubectl run 开始

使用最小的 Redis 镜像

部署

08 安全重点 认证和授权

08 安全重点 认证和授权

整体概览

认证（Authentication）

09 应用发布：部署实际项目

09 应用发布：部署实际项目

整体概览

构建镜像

前端

后端

Work

10 应用管理：初识 Helm

10 应用管理：初识 Helm

整体概览

Helm 介绍

Helm 安装

客户端 helm

11 部署实践：以 Helm 部署项目

11 部署实践：以 Helm 部署项目

概览

Helm chart

Chart 结构

Chart.yaml

charts

.helmignore

templates

12 庖丁解牛：kube-apiserver

12 庖丁解牛：kube-apiserver

整体概览

REST API Server

认证（Authentication）

13 庖丁解牛：etcd

13 庖丁解牛：etcd

整体概览

etcd 是什么

etcd 有什么作用

14 庖丁解牛：controller-manager

14 庖丁解牛：controller-manager

整体概览

kube-controller-manager 是什么

kube-controller-manager 有什么作用

15 庖丁解牛：kube-scheduler

08 安全重点认证和授权

08 安全重点认证和授权