写在前面
本文是K8S系列第二篇,主要面向对K8S新手同学,阅读本文需要读者对K8S的基本概念,比如Pod、Deployment、Service、Namespace等基础概念有所了解。尚且不熟悉的同学推荐先阅读本系列的第一篇文章:《K8S系列一:概念入门》
本文旨在讲述如何通过kubectl(kubernetes命令行工具)操作K8S集群、以及其集群上的服务等资源。本文的组织架构如下:
- 如何配置kubectl?
- 如何部署自己的服务?包括创建Pod、Deployment和Service。
- 如何查看、更新/编辑和删除服务?包括查看、更新/编辑和删除Pod、Deployment和Service。
- 如何排查自己部署的服务的问题?
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的问题。