K8S系列二：实战入门

I. 配置kubectl

1.1 什么是kubectl？

官方文档中介绍kubectl是：

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

也就是说，可以通过kubectl来操作K8S集群，官方文档中介绍其基本语法：

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

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

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

1.2 怎么配置kubectl？

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

apiVersion: v1
clusters:- cluster:certificate-authority-data: thisisfakecertifcateauthoritydata00000000000server: https://1.2.3.4:1234name: cls-dev
contexts:- context:cluster: cls-devuser: kubernetes-adminname: kubernetes-admin@test
current-context: kubernetes-admin@test
kind: Config
preferences: {}
users:- name: kubernetes-adminuser:token: thisisfaketoken00000

解读如下：

• clusters记录了clusters（一个或多个K8S集群）信息：
  • name是这个cluster（K8S集群）的名称代号
  • server是这个cluster（K8S集群）的访问方式，一般为IP+PORT
  • certificate-authority-data是证书数据，只有当cluster（K8S集群）的连接方式是https时，为了安全起见需要证书数据
• users记录了访问cluster（K8S集群）的账号信息：
  • name是用户账号的名称代号
  • user/token是用户的token认证方式，token不是用户认证的唯一方式，其他还有账号+密码等。
• contexts是上下文信息，包括了cluster（K8S集群）和访问cluster（K8S集群）的用户账号等信息：
  • name是这个上下文的名称代号
  • cluster是cluster（K8S集群）的名称代号
  • user是访问cluster（K8S集群）的用户账号代号
• current-context记录当前kubectl默认使用的上下文信息
• kind和apiVersion都是固定值，用户不需要关心
• preferences则是配置文件的其他设置信息，笔者没有使用过，暂时不提。

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

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

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

• kubectl config get-contexts。列出所有上下文信息。
  
• kubectl config current-context。查看当前的上下文信息。其实，命令1线束出来的*所指示的就是当前的上下文信息。
  
• kubectl config use-context ${CONTEXT_NAME}。更改上下文信息。
  
• kubectl config set-context{CONTEXT_NAME}|–current --{KEY}={VALUE}。
  修改上下文的元素。比如可以修改用户账号、集群信息、连接到K8S后所在的namespace。
  

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

• config set-context可以修改任何在配置文件中的上下文信息，只需要在命令中指定上下文名称就可以。而**–current则指代当前上下文**。
• 上下文信息所包括的内容有：cluster集群（名称）、用户账号（名称）、连接到K8S后所在的namespace，因此有config
  set-context严格意义上的用法： kubectl config set-context [NAME|–current]
  [–cluster=cluster_nickname] [–user=user_nickname]
  [–namespace=namespace] [options]
  （备注：[options]可以通过kubectl options查看）

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

II. kubectl部署服务

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

2.1 如何部署Pod？

通过kubectl部署Pod的办法分为两步：1). 准备Pod的yaml文件；2). 执行kubectl命令部署
第一步：准备Pod的yaml文件。关于Pod的yaml文件初步解释，本系列上一篇文章《K8S系列一：概念入门》已经有了初步介绍，这里再复习下：

apiVersion: v1
kind: Pod
metadata:name: memory-demonamespace: mem-example
spec:containers:- name: memory-demo-ctrimage: polinux/stressresources:limits:memory: "200Mi"requests:memory: "100Mi"command: ["stress"]args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]volumeMounts:- name: redis-storagemountPath: /data/redisvolumes:- name: redis-storageemptyDir: {}

继续解读：

• metadata，对于新入门的同学来说，需要重点掌握的两个字段：
  • name。这个Pod的名称，后面到K8S集群中查找Pod的关键字段。
  • namespace。命名空间，即该Pod隶属于哪个namespace下，关于Pod和namespace的关系，上一篇文章已经交代了。
• spec记录了Pod内部所有的资源的详细信息，这里我们重点查看containers下的几个重要字段：
  • name。Pod下该容器名称，后面查找Pod下的容器的关键字段。
  • image。容器的镜像地址，K8S会根据这个字段去拉取镜像。
  • resources。容器化服务涉及到的CPU、内存、GPU等资源要求。可以看到有limits和requests两个子项，那么这两者有什么区别吗，该怎么使用？在What’s
    the difference between Pod resources.limits and resources.requests in
    Kubernetes?回答了：
    limits是K8S为该容器至多分配的资源配额；而requests则是K8S为该容器至少分配的资源配额。打个比方，配置中要求了memory的requests为100M，而此时如果K8S集群中所有的Node的可用内存都不足100M，那么部署服务会失败；又如果有一个Node的内存有16G充裕，可以部署该Pod，而在运行中，该容器服务发生了内存泄露，那么一旦超过200M就会因为OOM被kill，尽管此时该机器上还有15G+的内存。
• command。容器的入口命令。对于这个笔者还存在很多困惑不解的地方，暂时挖个坑，有清楚的同学欢迎留言。
• args。容器的入口参数。同上，有清楚的同学欢迎留言。
• volumeMounts。容器要挂载的Pod数据卷等。请务必记住：Pod的数据卷只有被容器挂载后才能使用！

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

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

修正后，再次部署：

2.2 如何部署Deployment？

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

apiVersion: extensions/v1beta1kind: Deploymentmetadata:name: rss-sitenamespace: mem-examplespec:replicas: 2template:metadata:labels:app: webspec:containers:- name: memory-demo-ctrimage: polinux/stressresources:limits:emory: "200Mi"requests:memory: "100Mi"command: ["stress"]args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]volumeMounts:- name: redis-storagemountPath: /data/redisvolumes:- name: redis-storageemptyDir: {}

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

• metadata同Pod的yaml，这里提一点：如果没有指明namespace，那么就是用kubectl默认的namespace（如果kubectl配置文件中没有指明namespace，那么就是default空间）。
• spec，可以看到Deployment的spec字段是在Pod的spec内容外“包了一层”，那就来看Deployment有哪些需要注意的：
  • replicas。副本个数。也就是该Deployment需要起多少个相同的Pod，如果用户成功在K8S中配置了n（n>1）个，那么Deployment会确保在集群中始终有n个服务在运行。
  • template。
    • metadata，新手同学先不管这边的信息。
    • spec，会发现这完完全全是上文提到的Pod的spec内容，在这里写明了Deployment下属管理的每个Pod的具体内容。

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

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

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

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

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

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

3.1 如何查看服务？

请务必记得一个事情：在K8S中，一个独立的服务即对应一个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”是怎么回事呢？先不着急，我们慢慢看下去。

3.2 如何更新/编辑服务？

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

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

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

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

方法二：通过kubectl直接编辑K8S上的服务。命令为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)

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

3.3 如何删除服务？

在K8S上删除服务的操作非常简单，命令为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}。

IV. kubectl排查服务问题

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

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

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

4.1 K8S上部署服务失败了怎么排查？

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

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

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

4.2 K8S上部署的服务不正常怎么排查？

如果服务部署成功了，且状态为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进入到容器实例内部。之后，就是用户检查自己服务的日志来定位问题。

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

写在后面

本文是K8S系列文章第二篇，旨在第一篇基础上加深对K8S的理解，且鼓励大家一起动手使用K8S。如果文章中有纰漏，非常欢迎留言或者私信指出；有理解错误的地方，更是欢迎留言或者私信告知。

因为是实战入门，因此提到的命令相对是比较基础、常见的。也十分欢迎大家留言或者私信交流更多K8S的问题。