无法置入文档因为pdfl初始化失败

无法置入文档因为pdfl初始化失败

写在前面

笔者今年 9 月从端侧开发转到后台开发，第一个系统开发任务就强依赖了 Kubernetes，加之项目任务重、排期紧，必须马上对 Kubernetes 有概念上的了解。然而，很多所谓“Kubernetes 入门概念”的文章看的一头雾水，对于大部分新手来说并不友好。经历了几天痛苦地学习之后，回顾来看，Kubernetes 根本不复杂。于是，决心写下这篇文章，一方面希望对新手同学有帮助;另一方面，以文会友，希望能够有机会交流讨论技术。

本文组织方式：

Kubernetes 是什么，即作用和目的。涉及 Kubernetes 架构的整理，Master 和 Node 之间的关系，以及 Kubernetes 几个重要的组件：API Server、Scheduler、Controller、etcd 等。

Kubernetes 的重要概念，即 Kubernetes 的 API 对象，也就是常常听到的 Pod、Deployment、Service 等。

如何配置 kubectl，介绍 kubectl 工具和配置办法。

如何用 kubectl 部署服务。

如何用 kubectl 查看、更新/编辑、删除服务。

如何用 kubectl 排查部署在 Kubernetes 集群上的服务出现的问题。

1. Kubernetes 概览

1.1 Kubernetes 是什么？

先看官方介绍：

Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications. 用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。

翻译成大白话就是：“Kubernetes 是负责自动化运维管理多个 Docker 程序的集群”。那么问题来了：Docker 运行可方便了，为什么要用 Kubernetes，它有什么优势？

插一句题外话：

为什么 Kubernetes 要叫 Kubernetes 呢？维基百科已经交代了(老美对星际是真的痴迷)：

Kubernetes(在希腊语意为“舵手”或“驾驶员”)由 Joe Beda、Brendan Burns 和 Craig McLuckie 创立，并由其他谷歌工程师，包括 Brian Grant 和 Tim Hockin 等进行加盟创作，并由谷歌在 2014 年首次对外宣布 。该系统的开发和设计都深受谷歌的 Borg 系统的影响，其许多顶级贡献者之前也是 Borg 系统的开发者。在谷歌内部，Kubernetes 的原始代号曾经是 Seven，即星际迷航中的 Borg(博格人)。Kubernetes 标识中舵轮有七个轮辐就是对该项目代号的致意。

为什么 Kubernetes 的缩写是 K8S 呢？我个人赞同 Why Kubernetes is Abbreviated k8s[1] 中说的观点“嘛，写全称也太累了吧，不如整个缩写”。其实只保留首位字符，用具体数字来替代省略的字符个数的做法，还是比较常见的。

1.2 为什么是 Kubernetes？

试想下传统的后端部署办法：把程序包(包括可执行二进制文件、配置文件等)放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。

有问题吗？显然有!最大的一个问题在于：如果服务的请求量上来，已部署的服务响应不过来怎么办？传统的做法往往是，如果请求量、内存、CPU 超过阈值做了告警，运维马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。

问题出现了：从监控告警到部署服务，中间需要人力介入!那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢？

这，就是 Kubernetes 要做的事情：自动化运维管理 Docker(容器化)程序。

1.3 Kubernetes 怎么做？

我们已经知道了 Kubernetes 的核心功能：自动化运维管理多个容器化程序。那么 Kubernetes 怎么做到的呢？这里，我们从宏观架构上来学习 Kubernetes 的设计思想。首先看下图，图片来自文章 Components of Kubernetes Architecture[2]：

Kubernetes 是属于主从设备模型(Master-Slave 架构)，即有 Master 节点负责核心的调度、管理和运维，Slave 节点则在执行用户的程序。但是在 Kubernetes 中，主节点一般被称为 Master Node 或者 Head Node(本文采用 Master Node 称呼方式)，而从节点则被称为Worker Node 或者 Node(本文采用 Worker Node 称呼方式)。

要注意一点：Master Node 和 Worker Node 是分别安装了 Kubernetes 的 Master 和 Woker 组件的实体服务器，每个 Node 都对应了一台实体服务器(虽然 Master Node 可以和其中一个 Worker Node 安装在同一台服务器，但是建议 Master Node 单独部署)，所有 Master Node 和 Worker Node 组成了 Kubernetes 集群，同一个集群可能存在多个 Master Node 和 Worker Node。

首先来看Master Node都有哪些组件：

API Server，Kubernetes 的请求入口服务。API Server 负责接收 Kubernetes 所有请求(来自 UI 界面或者 CLI 命令行工具)，然后，API Server 根据用户的具体请求，去通知其他组件干活。

Scheduler，Kubernetes 所有 Worker Node 的调度器。当用户要部署服务时，Scheduler 会选择最合适的 Worker Node(服务器)来部署。

Controller Manager，Kubernetes 所有 Worker Node 的监控器。Controller Manager 有很多具体的 Controller，在文章 Components of Kubernetes Architecture[2] 中提到的有 Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node 上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候，Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。

etcd，Kubernetes 的存储服务。etcd 存储了 Kubernetes 的关键配置和用户配置，Kubernetes 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据(见 Kubernetes Works Like an Operating System[3])。

接着来看Worker Node的组件，笔者更赞同 HOW DO APPLICATIONS RUN ON KUBERNETES[4] 文章中提到的组件介绍：

Kubelet，Worker Node 的监视器，以及与 Master Node 的通讯器。Kubelet 是 Master Node 安插在 Worker Node 上的“眼线”，它会定期向 Master Node 汇报自己 Node 上运行的服务的状态，并接受来自 Master Node 的指示采取调整措施。

Kube-Proxy，Kubernetes 的网络代理。私以为称呼为 Network-Proxy 可能更适合？Kube-Proxy 负责 Node 在 Kubernetes 的网络通讯、以及对外部网络流量的负载均衡。

Container Runtime，Worker Node 的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如 Docker Engine。大白话就是帮忙装好了 Docker 运行环境。

Logging Layer，Kubernetes 的监控状态收集器。私以为称呼为 Monitor 可能更合适？Logging Layer 负责采集 Node 上所有服务的 CPU、内存、磁盘、网络等监控项信息。

Add-Ons，Kubernetes 管理运维 Worker Node 的插件组件。有些文章认为 Worker Node 只有三大组件，不包含 Add-On，但笔者认为 Kubernetes 系统提供了 Add-On 机制，让用户可以扩展更多定制化功能，是很不错的亮点。

总结来看，Kubernetes 的 Master Node 具备：请求入口管理(API Server)，Worker Node 调度(Scheduler)，监控和自动调节(Controller Manager)，以及存储功能(etcd);而 Kubernetes 的 Worker Node 具备：状态和监控收集(Kubelet)，网络和负载均衡(Kube-Proxy)、保障容器化运行环境(Container Runtime)、以及定制化功能(Add-Ons)。

到这里，相信你已经对 Kubernetes 究竟是做什么的，有了大概认识。接下来，再来认识下 Kubernetes 的 Deployment、Pod、Replica Set、Service 等，但凡谈到 Kubernetes，就绕不开这些名词，而这些名词也是最让 Kubernetes 新手们感到头疼、困惑的。

2. Kubernetes 重要概念

2.1 Pod 实例

官方对于Pod的解释是：

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

这样的解释还是很难让人明白究竟 Pod 是什么，但是对于 Kubernetes 而言，Pod 可以说是所有对象中最重要的概念了!因此，我们必须首先清楚地知道“Pod 是什么”，再去了解其他的对象。

从官方给出的定义，联想下“最小的 xxx 单元”，是不是可以想到本科在学校里学习“进程”的时候，教科书上有一段类似的描述：资源分配的最小单位;还有”线程“的描述是：CPU 调度的最小单位。什么意思呢？“最小 xx 单位”要么就是事物的衡量标准单位，要么就是资源的闭包、集合。前者比如长度米、时间秒;后者比如一个“进程”是存储和计算的闭包，一个“线程”是 CPU 资源(包括寄存器、ALU 等)的闭包。

同样的，Pod 就是 Kubernetes 中一个服务的闭包。这么说的好像还是有点玄乎，更加云里雾里了。简单来说，Pod 可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。再打个形象的比喻，在同一个 Pod 里的几个 Docker 服务/程序，好像被部署在同一台机器上，可以通过 localhost 互相访问，并且可以共用 Pod 里的存储资源(这里是指 Docker 可以挂载 Pod 内的数据卷，数据卷的概念，后文会详细讲述，暂时理解为“需要手动 mount 的磁盘”)。笔者总结 Pod 如下图，可以看到：同一个 Pod 之间的 Container 可以通过 localhost 互相访问，并且可以挂载 Pod 内所有的数据卷;但是不同的 Pod 之间的 Container 不能用 localhost 访问，也不能挂载其他 Pod 的数据卷。

对 Pod 有直观的认识之后，接着来看 Kubernetes 中 Pod 究竟长什么样子，具体包括哪些资源？

Kubernetes 中所有的对象都通过 yaml 来表示，笔者从官方网站摘录了一个最简单的 Pod 的 yaml：

apiVersion: v1

kind: Pod

metadata:

name: memory-demo

namespace: mem-example

spec:

containers:

- name: memory-demo-ctr

image: polinux/stress

resources:

limits:

memory: "200Mi"

requests:

memory: "100Mi"

command: [ "stress"]

args: [ "--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

volumeMounts:

- name: redis-storage

mountPath: /data/redis

volumes:

- name: redis-storage

emptyDir: {}

看不懂不必慌张，且耐心听下面的解释：

apiVersion 记录 Kubernetes 的 API Server 版本，现在看到的都是 v1，用户不用管。

kind 记录该 yaml 的对象，比如这是一份 Pod 的 yaml 配置文件，那么值内容就是 Pod。

metadata 记录了 Pod 自身的元数据，比如这个 Pod 的名字、这个 Pod 属于哪个 namespace(命名空间的概念，后文会详述，暂时理解为“同一个命名空间内的对象互相可见”)。

spec 记录了 Pod 内部所有的资源的详细信息，看懂这个很重要：

containers 记录了 Pod 内的容器信息，containers 包括了：name 容器名，image 容器的镜像地址，resources 容器需要的 CPU、内存、GPU 等资源，command 容器的入口命令，args 容器的入口参数，volumeMounts 容器要挂载的 Pod 数据卷等。可以看到，上述这些信息都是启动容器的必要和必需的信息。

volumes 记录了 Pod 内的数据卷信息，后文会详细介绍 Pod 的数据卷。

2.2 Volume 数据卷

Kubernetes 支持很多类型的 Volume 数据卷挂载，具体请参见 Kubernetes 卷[5]。前文就“如何理解 Volume”提到：“需要手动 mount 的磁盘”，此外，有一点可以帮助理解：数据卷 Volume 是 Pod 内部的磁盘资源。

其实，单单就 Volume 来说，不难理解。但是上面还看到了 volumeMounts，这俩是什么关系呢？

Volume 是 Kubernetes 的对象，对应一个实体的数据卷;而 volumeMounts 只是 container 的挂载点，对应 container 的其中一个参数。但是，volumeMounts 依赖于 Volume，只有当 Pod 内有 Volume 资源的时候，该 Pod 内部的 container 才可能有 volumeMounts。

2.3 Container 容器

本文中提到的镜像 Image、容器 Container，都指代了 Pod 下的一个 container。关于 Kubernetes 中的容器，在 2.1 Pod 章节都已经交代了，这里无非再啰嗦一句：一个 Pod 内可以有多个容器 container。

在 Pod 中，容器也有分类，对这个感兴趣的同学欢迎自行阅读更多资料：

标准容器(Application Container)。

初始化容器(Init Container)。

边车容器(Sidecar Container)。

临时容器(Ephemeral Container)。

一般来说，我们部署的大多是标准容器(Application Container)。

2.4 Deployment 和 ReplicaSet(简称 RS)

除了 Pod 之外，Kubernetes 中最常听到的另一个对象就是 Deployment 了。那么，什么是 Deployment 呢？官方给出了一个要命的解释：

一个 Deployment 控制器为 Pods 和 ReplicaSets 提供声明式的更新能力。你负责描述 Deployment 中的目标状态，而 Deployment 控制器以受控速率更改实际状态，使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，并通过新的 Deployment 收养其资源。

翻译一下：Deployment 的作用是管理和控制 Pod 和 ReplicaSet，管控它们运行在用户期望的状态中。哎，打个形象的比喻，Deployment 就是包工头，主要负责监督底下的工人 Pod 干活，确保每时每刻有用户要求数量的 Pod 在工作。如果一旦发现某个工人 Pod 不行了，就赶紧新拉一个 Pod 过来替换它。

新的问题又来了：那什么是 ReplicaSets 呢？

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

再来翻译下：ReplicaSet 的作用就是管理和控制 Pod，管控他们好好干活。但是，ReplicaSet 受控于 Deployment。形象来说，ReplicaSet 就是总包工头手下的小包工头。

笔者总结得到下面这幅图，希望能帮助理解：

新的问题又来了：如果都是为了管控 Pod 好好干活，为什么要设置 Deployment 和 ReplicaSet 两个层级呢，直接让 Deployment 来管理不可以吗？

回答：不清楚，但是私以为是因为先有 ReplicaSet，但是使用中发现 ReplicaSet 不够满足要求，于是又整了一个 Deployment(有清楚 Deployment 和 ReplicaSet 联系和区别的小伙伴欢迎留言啊)。

但是，从 Kubernetes 使用者角度来看，用户会直接操作 Deployment 部署服务，而当 Deployment 被部署的时候，Kubernetes 会自动生成要求的 ReplicaSet 和 Pod。在 Kubernetes 官方文档中也指出用户只需要关心 Deployment 而不操心 ReplicaSet：

This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead, and define your application in the spec section.这实际上意味着您可能永远不需要操作 ReplicaSet 对象：直接使用 Deployments 并在规范部分定义应用程序。

补充说明：在 Kubernetes 中还有一个对象 —— ReplicationController(简称 RC)，官方文档对它的定义是：

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

怎么样，和 ReplicaSet 是不是很相近？在 Deployments, ReplicaSets, and pods[6] 教程中说“ReplicationController 是 ReplicaSet 的前身”，官方也推荐用 Deployment 取代 ReplicationController 来部署服务。

2.5 Service 和 Ingress

吐槽下 Kubernetes 的概念/对象/资源是真的多啊!前文介绍的 Deployment、ReplicationController 和 ReplicaSet 主要管控 Pod 程序服务;那么，Service 和 Ingress 则负责管控 Pod 网络服务。

我们先来看看官方文档中 Service 的定义：

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。

翻译下：Kubernetes 中的服务(Service)并不是我们常说的“服务”的含义，而更像是网关层，是若干个 Pod 的流量入口、流量均衡器。

那么，为什么要 Service 呢？

私以为在这一点上，官方文档讲解地非常清楚：

Kubernetes Pod 是有生命周期的。它们可以被创建，而且销毁之后不会再启动。如果您使用 Deployment 来运行您的应用程序，则它可以动态创建和销毁 Pod。每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。这导致了一个问题：如果一组 Pod(称为“后端”)为群集内的其他 Pod(称为“前端”)提供功能， 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？

补充说明：Kubernetes 集群的网络管理和拓扑也有特别的设计，以后会专门出一章节来详细介绍 Kubernetes 中的网络。这里需要清楚一点：Kubernetes 集群内的每一个 Pod 都有自己的 IP(是不是很类似一个 Pod 就是一台服务器，然而事实上是多个 Pod 存在于一台服务器上，只不过是 Kubernetes 做了网络隔离)，在 Kubernetes 集群内部还有 DNS 等网络服务(一个 Kubernetes 集群就如同管理了多区域的服务器，可以做复杂的网络拓扑)。

此外，笔者推荐 Kubernetes 外网如何访问业务应用对于 Service 的介绍，不过对于新手而言，推荐阅读前半部分对于 service 的介绍即可，后半部分就太复杂了。我这里做了简单的总结：

Service 是 Kubernetes 服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。举个例子，我们的一个服务 A，部署了 3 个备份，也就是 3 个 Pod;对于用户来说，只需要关注一个 Service 的入口就可以，而不需要操心究竟应该请求哪一个 Pod。优势非常明显：一方面外部用户不需要感知因为 Pod 上服务的意外崩溃、Kubernetes 重新拉起 Pod 而造成的 IP 变更，外部用户也不需要感知因升级、变更服务带来的 Pod 替换而造成的 IP 变化，另一方面，Service 还可以做流量负载均衡。

但是，Service 主要负责 Kubernetes 集群内部的网络拓扑。那么集群外部怎么访问集群内部呢？这个时候就需要 Ingress 了，官方文档中的解释是：

Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。

翻译一下：Ingress 是整个 Kubernetes 集群的接入层，复杂集群内外通讯。

最后，笔者把 Ingress 和 Service 的关系绘制网络拓扑关系图如下，希望对理解这两个概念有所帮助：

2.6 namespace 命名空间

和前文介绍的所有的概念都不一样，namespace 跟 Pod 没有直接关系，而是 Kubernetes 另一个维度的对象。或者说，前文提到的概念都是为了服务 Pod 的，而 namespace 则是为了服务整个 Kubernetes 集群的。

那么，namespace 是什么呢？

上官方文档定义：

Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。这些虚拟集群被称为名字空间。

翻译一下：namespace 是为了把一个 Kubernetes 集群划分为若干个资源不可共享的虚拟集群而诞生的。

也就是说，可以通过在 Kubernetes 集群内创建 namespace 来分隔资源和对象。比如我有 2 个业务 A 和 B，那么我可以创建 ns-a 和 ns-b 分别部署业务 A 和 B 的服务，如在 ns-a 中部署了一个 deployment，名字是 hello，返回用户的是“hello a”;在 ns-b 中也部署了一个 deployment，名字恰巧也是 hello，返回用户的是“hello b”(要知道，在同一个 namespace 下 deployment 不能同名;但是不同 namespace 之间没有影响)。前文提到的所有对象，都是在 namespace 下的;当然，也有一些对象是不隶属于 namespace 的，而是在 Kubernetes 集群内全局可见的，官方文档提到的可以通过命令来查看，具体命令的使用办法，笔者会出后续的实战文章来介绍，先贴下命令：

# 位于名字空间中的资源

kubectl api-resources --namespaced= true

# 不在名字空间中的资源

kubectl api-resources --namespaced= false

不在 namespace 下的对象有：

在 namespace 下的对象有(部分)：

2.7 其他

Kubernetes 的对象实在太多了，2.1-2.6 介绍的是在实际使用 Kubernetes 部署服务最常见的。其他的还有 Job、CronJob 等等，在对 Kubernetes 有了比较清楚的认知之后，再去学习更多的 Kubernetes 对象，不是难事。

3. 配置 kubectl

3.1 什么是 kubectl？

官方文档中介绍 kubectl 是：

Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。Kubectl 的配置文件在$HOME/.kube 目录。我们可以通过设置 KUBECONFIG 环境变量或设置命令参数--kubeconfig 来指定其他位置的 kubeconfig 文件。

也就是说，可以通过 kubectl 来操作 Kubernetes 集群，基本语法：

使用以下语法 kubectl 从终端窗口运行命令：

kubectl [ command] [TYPE] [NAME] [flags]

其中 command、TYPE、NAME 和 flags 分别是：

command：指定要对一个或多个资源执行的操作，例如 create、get、describe、delete。

TYPE：指定资源类型。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果：

kubectl get pod pod1

kubectl get pods pod1

kubectl get po pod1

NAME：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 kubectl get pods。

在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件：

要按类型和名称指定资源：

要对所有类型相同的资源进行分组，请执行以下操作：TYPE1 name1 name2 name<#>。 例子：kubectl get pod example-pod1 example-pod2

分别指定多个资源类型：TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>。 例子：kubectl get pod/example-pod1 replicationcontroller/example-rc1

用一个或多个文件指定资源：-f file1 -f file2 -f file<#>

使用 YAML 而不是 JSON 因为 YAML 更容易使用，特别是用于配置文件时。 例子：kubectl get -f ./pod.yaml

flags：指定可选的参数。例如，可以使用 -s 或 -server 参数指定 Kubernetes API 服务器的地址和端口。

就如何使用 kubectl 而言，官方文档已经说得非常清楚。不过对于新手而言，还是需要解释几句：kubectl 是 Kubernetes 的命令行工具，并不需要 kubectl 安装在 Kubernetes 集群的任何 Node 上，但是，需要确保安装 kubectl 的机器和 Kubernetes 的集群能够进行网络互通。

接下来，一起看看怎么使用 kubectl 吧，切身感受下 kubectl 的使用。

请注意，如何安装 kubectl 的办法有许多非常明确的教程，比如《安装并配置 kubectl[7]》，本文不再赘述。

3.2 怎么配置 kubectl？

第一步，必须准备好要连接/使用的 Kubernetes 的配置文件，笔者给出一份杜撰的配置：

apiVersion: v1

clusters:

- cluster:

certificate-authority-data: thisisfakecertifcateauthoritydata00000000000

server: https://1.2.3.4:1234

name: cls-dev

contexts:

- context:

cluster: cls-dev

user: kubernetes-admin

name: kubernetes-admin@ test

current-context: kubernetes-admin@ test

kind: Config

preferences: {}

users:

- name: kubernetes-admin

user:

token: thisisfaketoken00000

解读如下：

clusters 记录了 clusters(一个或多个 Kubernetes 集群)信息：

name 是这个 cluster(Kubernetes 集群)的名称代号

server 是这个 cluster(Kubernetes 集群)的访问方式，一般为 IP+PORT

certificate-authority-data 是证书数据，只有当 cluster(Kubernetes 集群)的连接方式是 https 时，为了安全起见需要证书数据

users 记录了访问 cluster(Kubernetes 集群)的账号信息：

name 是用户账号的名称代号

user/token 是用户的 token 认证方式，token 不是用户认证的唯一方式，其他还有账号+密码等。

contexts 是上下文信息，包括了 cluster(Kubernetes 集群)和访问 cluster(Kubernetes 集群)的用户账号等信息：

name 是这个上下文的名称代号

cluster 是 cluster(Kubernetes 集群)的名称代号

user 是访问 cluster(Kubernetes 集群)的用户账号代号

current-context 记录当前 kubectl 默认使用的上下文信息

kind 和 apiVersion 都是固定值，用户不需要关心

preferences 则是配置文件的其他设置信息，笔者没有使用过，暂时不提。

第二步，给 kubectl 配置上配置文件。

--kubeconfig 参数。第一种办法是每次执行 kubectl 的时候，都带上 --kubeconfig=${CONFIG_PATH}。给一点温馨小提示：每次都带这么一长串的字符非常麻烦，可以用 alias 别名来简化码字量，比如 alias k=kubectl --kubeconfig=${CONFIG_PATH}。

KUBECONFIG 环境变量。第二种做法是使用环境变量 KUBECONFIG 把所有配置文件都记录下来，即 export KUBECONFIG=$KUBECONFIG:${CONFIG_PATH}。接下来就可以放心执行 kubectl 命令了。

$HOME/.kube/config 配置文件。第三种做法是把配置文件的内容放到 $HOME/.kube/config 内。具体做法为：

如果$HOME/.kube/config 不存在，那么cp ${CONFIG_PATH} $HOME/.kube/config即可;

如果如果 $HOME/.kube/config已经存在，那么需要把新的配置内容加到 $HOME/.kube/config 下。单单只是cat ${CONFIG_PATH} >> $HOME/.kube/config是不行的，正确的做法是：KUBECONFIG=$HOME/.kube/config:${CONFIG_PATH} kubectl config view --flatten > $HOME/.kube/config 。解释下这个命令的意思：先把所有的配置文件添加到环境变量KUBECONFIG中，然后执行kubectl config view --flatten打印出有效的配置文件内容，最后覆盖$HOME/.kube/config 即可。

请注意，上述操作的优先级分别是 1>2>3，也就是说，kubectl 会优先检查--kubeconfig，若无则检查KUBECONFIG，若无则最后检查$HOME/.kube/config，如果还是没有，报错。但凡某一步找到了有效的 cluster，就中断检查，去连接 Kubernetes 集群了。

第三步：配置正确的上下文。

按照第二步的做法，如果配置文件只有一个 cluster 是没有任何问题的，但是对于有多个 cluster 怎么办呢？到这里，有几个关于配置的必须掌握的命令：

kubectl config get-contexts。列出所有上下文信息。

kubect l config current-context。 查看当前的上下文信息。 其实，命令 1 线束出来的*所指示的就是当前的上下文信息。

kubectl config use-context ${CONTEXT_NAME}。 更改上下文信息。

kubectl config set-context ${CONTEXT_NAME}|--current --${KEY}=${VALUE}。 修改上下文的元素。 比如可以修改用户账号、集群信息、连接到 Kubernetes 后所在的 namespace。

关于该命令，还有几点要啰嗦的：

config set-context可以修改任何在配置文件中的上下文信息，只需要在命令中指定上下文名称就可以。而--current 则指代当前上下文。

上下文信息所包括的内容有：cluster 集群(名称)、用户账号(名称)、连接到 Kubernetes 后所在的 namespace，因此有 config set-context 严格意义上的用法：

kubectl config set-context [NAME|--current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace] [options]

备注：[options]可以通过 kubectl options 查看。

综上，如何操作 kubectl 配置都已交代。

？？？？？？4. kubectl 部署服务

？？？？？？

Kubernetes 核心功能就是部署运维容器化服务，因此最重要的就是如何又快又好地部署自己的服务了。本章会介绍如何部署 Pod 和 Deployment。

4.1 如何部署 Pod？

通过 kubectl 部署 Pod 的办法分为两步：1). 准备 Pod 的 yaml 文件;2). 执行 kubectl 命令部署。

第一步：准备 Pod 的 yaml 文件。关于 Pod 的 yaml 文件初步解释，本文已经有了初步介绍，这里再复习下：

apiVersion: v1

kind: Pod

metadata:

name: memory-demo

namespace: mem-example

spec:

containers:

- name: memory-demo-ctr

image: polinux/stress

resources:

limits:

memory: "200Mi"

requests:

memory: "100Mi"

command: [ "stress"]

args: [ "--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

volumeMounts:

- name: redis-storage

mountPath: /data/redis

volumes:

- name: redis-storage

emptyDir: {}

继续解读：

metadata，对于新入门的同学来说，需要重点掌握的两个字段：

name，这个 Pod 的名称，后面到 Kubernetes 集群中查找 Pod 的关键字段。

namespace，命名空间，即该 Pod 隶属于哪个 namespace 下，关于 Pod 和 namespace 的关系，之前内容已经交代了。

spec 记录了 Pod 内部所有的资源的详细信息，这里我们重点查看 containers 下的几个重要字段：

name，Pod 下该容器名称，后面查找 Pod 下的容器的关键字段。

image，容器的镜像地址，Kubernetes 会根据这个字段去拉取镜像。

resources，容器化服务涉及到的 CPU、内存、GPU 等资源要求。可以看到有 limits 和 requests 两个子项，那么这两者有什么区别吗，该怎么使用？在 What's the difference between Pod resources.limits and resources.requests in Kubernetes?[8] 回答了：limits是 Kubernetes 为该容器至多分配的资源配额;而 requests 则是 Kubernetes 为该容器至少分配的资源配额。打个比方，配置中要求了 memory 的 requests 为 100M，而此时如果 Kubernetes 集群中所有的 Node 的可用内存都不足 100M，那么部署服务会失败;又如果有一个 Node 的内存有 16G 充裕，可以部署该 Pod，而在运行中，该容器服务发生了内存泄露，那么一旦超过 200M 就会因为 OOM 被 kill，尽管此时该机器上还有 15G+的内存。

command，容器的入口命令。对于这个笔者还存在很多困惑不解的地方，暂时挖个坑，有清楚的同学欢迎留言。

args，容器的入口参数。同上，有清楚的同学欢迎留言。

volumeMounts，容器要挂载的 Pod 数据卷等。请务必记住：Pod 的数据卷只有被容器挂载后才能使用!

第二步：执行 kubectl 命令部署。有了 Pod 的 yaml 文件之后，就可以用 kubectl 部署了，命令非常简单：kubectl create -f ${POD_YAML}。

随后，会提示该命令是否执行成功，比如 yaml 内容不符合要求，则会提示哪一行有问题：

修正后，再次部署：

4.2 如何部署 Deployment？

第一步：准备 Deployment 的 yaml 文件。首先来看 Deployment 的 yaml 文件内容：

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: rss-site

namespace: mem-example

spec:

replicas: 2

template:

metadata:

labels:

app: web

spec:

containers:

- name: memory-demo-ctr

image: polinux/stress

resources:

limits:

emory: "200Mi"

requests:

memory: "100Mi"

command: [ "stress"]

args: [ "--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

volumeMounts:

- name: redis-storage

mountPath: /data/redis

volumes:

- name: redis-storage

emptyDir: {}

继续来看几个重要的字段：

metadata 同 Pod 的 yaml，这里提一点：如果没有指明 namespace，那么就是用 kubectl 默认的 namespace(如果 kubectl 配置文件中没有指明 namespace，那么就是 default 空间)。

spec，可以看到 Deployment 的 spec 字段是在 Pod 的 spec 内容外“包了一层”，那就来看 Deployment 有哪些需要注意的：

metadata，新手同学先不管这边的信息。

spec，会发现这完完全全是上文提到的 Pod 的 spec 内容，在这里写明了 Deployment 下属管理的每个 Pod 的具体内容。

replicas，副本个数。也就是该 Deployment 需要起多少个相同的 Pod，如果用户成功在 Kubernetes 中配置了 n(n>1)个，那么 Deployment 会确保在集群中始终有 n 个服务在运行。

template。

第二步：执行 kubectl 命令部署。Deployment 的部署办法同 Pod：kubectl create -f ${DEPLOYMENT_YAML}。由此可见，Kubernetes 会根据配置文件中的kind字段来判断具体要创建的是什么资源。

这里插一句题外话：部署完 Deployment 之后，可以查看到自动创建了 ReplicaSet 和 Pod，如下图所示：

还有一个有趣的事情：通过 Deployment 部署的服务，其下属的 RS 和 Pod 命名是有规则的。读者朋友们自己总结发现哦。

综上，如何部署一个 Pod 或者 Deployment 就结束了。

5. kubectl 查看、更新/编辑、删除服务

作为 Kubernetes 使用者而言，更关心的问题应该是本章所要讨论的话题：如何通过 kubectl 查看、更新/编辑、删除在 Kubernetes 上部署着的服务。

5.1 如何查看服务？

请务必记得一个事情：在 Kubernetes 中，一个独立的服务即对应一个 Pod。即，当我们说要 xxx 一个服务的就是，也就是操作一个 Pod。而与 Pod 服务相关的且需要用户关心的，有 Deployment。

通过 kubectl 查看服务的基本命令是：

$ kubectl get|describe ${RESOURCE}[-o ${FORMAT}] -n= ${NAMESPACE}

# ${RESOURCE}有: pod、deployment、replicaset(rs)

在此之前，还有一个需要回忆的事情是：Deployment、ReplicaSet 和 Pod 之间的关系 —— 层层隶属;以及这些资源和 namespace 的关系是 —— 隶属。如下图所示：

因此，要查看一个服务，也就是一个 Pod，必须首先指定 namespace!那么，如何查看集群中所有的 namespace 呢？kubectl get ns：

于是，只需要通过 -n=${NAMESPACE} 就可以指定自己要操作的资源所在的 namespace。比如查看 Pod：kubectl get pod -n=oona-test，同理，查看 Deployment：kubectl get deployment -n=oona-test。

问题又来了：如果已经忘记自己所部属的服务所在的 namespace 怎么办？这么多 namespace，一个一个查看过来吗？

kubectl get pod --all-namespaces

这样子就可以看到所有 namespace 下面部署的 Pod 了!同理，要查找所有的命名空间下的 Deployment 的命令是：kubectl get deployment --all-namespaces。

于是，就可以开心地查看 Pod：kubectl get pod [-o wide] -n=oona-test，或者查看 Deployment：kubectl get deployment [-o wide] -n=oona-test。

哎，这里是否加 -o wide 有什么区别吗？实际操作下就明白了，其他资源亦然：

哎，我们看到之前部署的 Pod 服务 memory-demo 显示的“ImagePullBackOff”是怎么回事呢？先不着急，我们慢慢看下去。

5.2 如何更新/编辑服务？

两种办法：1). 修改 yaml 文件后通过 kubectl 更新;2). 通过 kubectl 直接编辑 Kubernetes 上的服务。

方法一：修改 yaml 文件后通过 kubectl 更新。我们看到，创建一个 Pod 或者 Deployment 的命令是 kubectl create -f ${YAML}。但是，如果 Kubernetes 集群当前的 namespace 下已经有该服务的话，会提示资源已经存在：

通过 kubectl 更新的命令是 kubectl apply -f ${YAML}，我们再来试一试：

备注：命令 kubectl apply -f ${YAML} 也可以用于首次创建一个服务哦。

方法二：通过 kubectl 直接编辑 Kubernetes 上的服务。命令为kubectl edit ${RESOURCE} ${NAME}，比如修改刚刚的 Pod 的命令为kubectl edit pod memory-demo，然后直接编辑自己要修改的内容即可。

但是请注意，无论方法一还是方法二，能修改的内容还是有限的，从笔者实战下来的结论是：只能修改/更新镜像的地址和个别几个字段。如果修改其他字段，会报错：

The Pod "memory-demo" is invalid: spec: Forbidden: pod updates may not change fields other than spec.containers[].image, spec.initContainers[].image, spec.activeDeadlineSeconds or spec.tolerations (only additions to existing tolerations)

如果真的要修改其他字段怎么办呢？恐怕只能删除服务后重新部署了。

5.3 如何删除服务？

在 Kubernetes 上删除服务的操作非常简单，命令为 kubectl delete ${RESOURCE} ${NAME}。比如删除一个 Pod 是：kubectl delete pod memory-demo，再比如删除一个 Deployment 的命令是：kubectl delete deployment ${DEPLOYMENT_NAME}。但是，请注意：

如果只部署了一个 Pod，那么直接删除该 Pod 即可;

如果是通过 Deployment 部署的服务，那么仅仅删除 Pod 是不行的，正确的删除 方式应该是：先删除 Deployment，再删除 Pod。

关于第二点应该不难想象：仅仅删除了 Pod 但是 Deployment 还在的话，Deployment 定时会检查其下属的所有 Pod，如果发现失败了则会再拉起。因此，会发现过一会儿，新的 Pod 又被拉起来了。

另外，还有一个事情：有时候会发现一个 Pod 总也删除不了，这个时候很有可能要实施强制删除措施，命令为 kubectl delete pod --force --grace-period=0 ${POD_NAME}。

6. kubectl 排查服务问题

上文说道：部署的服务 memory-demo 失败了，是怎么回事呢？本章就会带大家一起来看看常见的 Kubernetes 中服务部署失败、服务起来了但是不正常运行都怎么排查呢？

首先，祭出笔者最爱的一张 Kubernetes 排查手册，来自博客《 Kubernetes Deployment 故障排除图解指南 》：

哈哈哈，对于新手同学来说，上图还是不够友好，下面我们简单来看两个例子：

6.1 Kubernetes 上部署服务失败了怎么排查？

请一定记住这个命令：kubectl describe ${RESOURCE} ${NAME}。比如刚刚的 Pod 服务 memory-demo，我们来看：

拉到最后看到Events部分，会显示出 Kubernetes 在部署这个服务过程的关键日志。这里我们可以看到是拉取镜像失败了，好吧，大家可以换一个可用的镜像再试试。

一般来说，通过 kubectl describe pod ${POD_NAME} 已经能定位绝大部分部署失败的问题了，当然，具体问题还是得具体分析。大家如果遇到具体的报错，欢迎分享交流。

6.2 Kubernetes 上部署的服务不正常怎么排查？

如果服务部署成功了，且状态为 running，那么就需要进入 Pod 内部的容器去查看自己的服务日志了：

查看 Pod 内部某个 container 打印的日志：kubectl log ${POD_NAME} -c ${CONTAINER_NAME}。

进入 Pod 内部某个 container：kubectl exec -it [options] ${POD_NAME} -c ${CONTAINER_NAME} [args]，嗯，这个命令的作用是通过 kubectl 执行了 docker exec xxx 进入到容器实例内部。之后，就是用户检查自己服务的日志来定位问题。

显然，线上可能会遇到更复杂的问题，需要借助更多更强大的命令和工具。

写在后面

本文希望能够帮助对 Kubernetes 不了解的新手快速了解 Kubernetes。笔者一边写文章，一边查阅和整理 Kubernetes 资料，过程中越发感觉 Kubernetes 架构的完备、设计的精妙，是值得深入研究的，Kubernetes 大受欢迎是有道理的。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。