在bash中设置当前shell的自动补全,要先安装bash-completion
包。
source <(kubectl completion bash)
在bash shell中永久地添加自动补全:
echo "source <(kubectl completion bash)" >> ~/.bashrc
在zsh中设置当前shell的自动补全:
source <(kubectl completion zsh)
在zsh shell 中永久地添加自动补全:
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc
kubectl config view
kubectl config use-context my-cluster-name
kubectl create -f xxx.yaml
kubectl apply -f xxx.yaml
区别:
apply
通过定义 Kubernetes 资源的文件来管理应用。 它通过运行kubectl apply
在集群中创建和更新资源。 这是在生产中管理 Kubernetes 应用的推荐方法。 参见 Kubectl 文档。
创建多个应用:
kubectl create -f A.yaml -f B.yaml
kubectl create -f A.yaml,B.yaml
两种方式都可以,第二种不支持tab补全。
kubectl create deployment nginx --image=nginx
nginx
为资源名称,指定镜像--image
,命令后面还可以接-n
指定namespace
,不指定则默认为default namespace
。
以yaml
格式输出配置信息:
kubectl get deployments.apps nginx -oyaml
不创建资源,通过--dry-run
只显示yaml
配置:
kubectl create deployment nginx --image=nginx --dry-run=client -oyaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: nginx
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
resources: {}
status: {}
通过>
重定向写入到yaml文件,之后可通过yaml文件去创建:
kubectl create deployment nginx2 --image=nginx --dry-run=client -oyaml > nginx2-dp.yaml
kubectl create -f nginx2-dp.yaml
kubectl get deployments.apps
kubectl delete deployments.apps app
同时也可以通过yaml文件删除:
kubectl delete -f app.yaml
删除dashboard的pod:
kubectl delete pod dashboard-metrics-scraper-6d57655c59-qqpzp -n kubernetes-dashboard
删除后pod会被自动重建起来:
因为pod是被deployment
管理的,当只有删掉deployment
,pod才能被彻底删除。
如果使用delete -f xx.yaml
删除时,yaml
文件里面没有指定namespace,则需要通过-n参数手动指定,如:
kubectl delete -f xxx.yaml -n kube-system
查看当前命名空间下的所有services:
kubectl get services #services可以缩写成svc
查看所有命名空间的全部Pods:
kubectl get pods --all-namespaces #--all-namespaces可以缩写成-A
如,以扩展形式查看kub-system
命名空间的pod信息:
kubectl get pod -A -owide -n kub-system
将会显示更多列信息,其中也包括IP地址(如果资源有IP地址的概念)。
扩展格式显示deployment
、service
的资源信息:
kubectl get deployments.apps -n kube-system -o wide
kubectl get svc -n kube-system -owide
列出所支持的全部资源类型和它们的简称、API 组, 是否是名字空间作用域 和 Kind。
kubectl api-resources
列出所有命名空间作用域的资源:
kubectl api-resources --namespaced=true
列出所有非命名空间作用域的资源,没有命名空间的则说明无法通过命名空间隔离:
kubectl api-resources --namespaced=false
用简单格式列举所有资源(仅显示资源名称:-o name
):
kubectl api-resources -o name
列出支持list
和get
请求的所有资源:
kubectl api-resources --verbs=list,get
列出extensions
API 组中的所有资源:
kubectl api-resources --api-group=extensions
以service的metadata
字段里的name
排序,也就是从.yaml
文件里面取数据:
kubectl get service -n kube-system --sort-by=.metadata.name
同理,从spec
字段的clusterIP
排序:
kubectl get service -n kube-system --sort-by=.spec.clusterIP
列出 Pods,按重启次数排序
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
containerStatuses[0]
表示containerStatuses的第0个元素的值。
-l
为label的意思,通过标签过滤。
过滤k8s-app
标签为calico-node
的容器:
kubectl get pods -n kube-system -l k8s-app=calico-node
同理,过滤标签为k8s-app=kube-dns
的deployment
的资源,并且扩展输出:
kubectl get deployments.apps -n kube-system -o wide -l k8s-app=kube-dns
输出pod信息时,过滤calico-node
的pod,并且显示标签信息
kubectl get pods -n kube-system -l k8s-app=calico-node --show-labels
显示deployment
的标签:
kubectl get deployments.apps -n kube-system --show-labels
同理,显示service
的标签:
kubectl get svc -n kube-system --show-labels
kubectl get pods -A --field-selector=status.phase=Running
滚动更新frontend
的www
容器镜像:
kubectl set image deployment/frontend www=image:v2
比如更新deployment
里的nginx镜像,更新到v2版本:
kubectl set image deployment/nginx nginx=nginx=v2
更新前:
更新后:
创建nginx3.yaml
配置文件:
kubectl create deployment nginx3 --image=nginx --dry-run=client -oyaml > nginx3.yaml
通过此配置文件创建nginx3的deployment:
kubectl apply -f nginx3.yaml
之后修改这个yaml文件,将nginx
改成nginx:v2
,再通过apply
来更新配置:
kubectl apply -f nginx3.yaml
此时可以看到,镜像更新成功:
编辑deployment
里的nginx
容器:
kubectl edit deployments.apps nginx
可以编辑里面的任何内容,比如把基础镜像升级到v2版本,则将imgae: nginx
改成image: nginx:v2
。
同理,也可以编辑serviced
:
kubectl edit svc/docker-registry
修改编辑操作时用的默认编辑器:
KUBE_EDITOR="nano" kubectl edit svc/docker-registry
单次使用生效,如果想永久生效则将此变量申明为环境变量:
bash下,写到~/.bashrc
里面:
echo 'export KUBE_EDITOR="nano"' >> ~/.bashrc
zsh下,写到~/.zshrc
里面:
echo 'export KUBE_EDITOR="nano"' >> ~/.zshrc
修改yaml文件后,用replace
来替换升级:
kubectl replace -f nginx3.yaml #这里也可以用apply,效果一样
往yaml加了个标签,可以看到replace
之后,标签成功加上。
kubectl logs my-pod
kubectl logs -f my-pod
kubectl logs --tail 10 my-pod #获取后10行
当一个pod里面有多个container时,使用-c
来指定容器:
kubectl logs my-pod -c my-container
这里只有一个容器,可以通过-c
来指定。
给这个yaml文件,再加一个redis容器,则通过-c
指定redis容器来获取最后五行日志:
kubectl describe pod nginx3-6f47ffccb5-xjh8m
kubectl describe nodes k8s-node01|tail -n 10
kubectl exec my-pod -- cmd
kubectl exec my-pod -c my-container -- cmd
kubectl exec -ti my-pod -- bash
有些pod基础镜像没有bash,则用sh代替。
状态 | 说明 |
---|---|
Pending(挂起) | Pod已被Kubernetes系统接收,但仍有一个或多个容器未被创建,可以通过kubectl describe查看处于Pending状态的原因。 |
Running(运行中) | Pod已被绑定到一个节点上,并且所有的容器都已经被创建,而且至少有一个是运行状态,或者是正在启动或重启,可以通过kubectl logs查看Pod日志。 |
Succeeded(成功) | 所有容器都已终止,并且至少有一个容器以失败的方式终止,也就是说这个容器要么以非零状态退出,要么被系统终止,可以通过logs和describe查看Pod日志和状态。 |
Unknown(未知) | 通常是由于通信问题造成的无法获得Pod的状态。 |
ImagePullBackOffErrImagePull | 镜像拉取失败,一般是由于镜像不存在、网络不通或者需要登录认证引起的,可以使用describe命令查看具体原因。 |
CrashLoopBackOff | 容器启动失败,可以通过logs命令查看具体原因,一般为启动命令不正确,健康检查不通过等。 |
OOMKilled | 容器内存溢出,一般是容器的内存Limit设置的过小,或者程序本身有内存溢出,可以通过logs查看程序启动日志。 |
Terminating | Pod正在被删除,可以通过describe查看状态。 |
SysctlForbidden | Pod自定义了内核配置,但kubelet没有添加内核配置或配置的内核参数不支持,可以通过describe查看具体原因。 |
Completed | 容器内部主进程退出,一般计划任务执行结束会显示该状态,此时可以通过logs查看容器日志。 |
ContainerCreating | Pod正在创建,一般为正在下载镜像,或者有配置不当的地方,可以通过describe查看具体原因。 |
附带PDF版本:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。