kubectl命令大全
进大厂,身价翻倍的法宝来了!
主讲内容：docker/kubernetes 云原生技术，大数据架构，分布式微服务，自动化测试、运维。
视频地址：ke.qq.com/course/419718
全栈工程师开发手册 （作者：栾鹏）
架构系列文章
kubectl 安装
参考https://blog.csdn.net/luanpeng825485697/article/details/80862581 文章中kubectl部分
linux命令行通过tab键自动补全的方式
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc
kubectl annotate – 更新资源的注解。
kubectl api-versions – 以“组/版本”的格式输出服务端支持的API版本。
kubectl apply – 通过文件名或控制台输入，对资源进行配置。
kubectl attach – 连接到一个正在运行的容器。
kubectl autoscale – 对replication controller进行自动伸缩。
kubectl cluster-info – 输出集群信息。
kubectl config – 修改kubeconfig配置文件。
kubectl create – 通过文件名或控制台输入，创建资源。
kubectl delete – 通过文件名、控制台输入、资源名或者label selector删除资源。
kubectl describe – 输出指定的一个/多个资源的详细信息。
kubectl edit – 编辑服务端的资源。
kubectl exec – 在容器内部执行命令。
kubectl expose – 输入replication controller，service或者pod，并将其暴露为新的kubernetes service。
kubectl get – 输出一个/多个资源。
kubectl label – 更新资源的label。
kubectl logs – 输出pod中一个容器的日志。
kubectl namespace -（已停用）设置或查看当前使用的namespace。
kubectl patch – 通过控制台输入更新资源中的字段。
kubectl port-forward – 将本地端口转发到Pod。
kubectl proxy – 为Kubernetes API server启动代理服务器。
kubectl replace – 通过文件名或控制台输入替换资源。
kubectl rolling-update – 对指定的replication controller执行滚动升级。
kubectl run – 在集群中使用指定镜像启动容器。
kubectl scale – 为replication controller设置新的副本数。
kubectl stop – （已停用）通过资源名或控制台输入安全删除资源。
kubectl version – 输出服务端和客户端的版本信息。
kubectl cordon 设定node不可使用|
kubectl uncordon 设定node可以使用|
kubectl drain 设定node进入维护模式|
kubectl 输出格式
显示Pod的更多信息
kubectl get pod -o wide
以yaml格式显示Pod的详细信息
kubectl get pod -o yaml
kubectl 操作示例
创建资源对象create
kubectl命令用于根据文件或输入创建集群resource。如果已经定义了相应resource的yaml或son文件
根据yaml配置文件一次性创建service和rc
kubectl create -f my-service.yaml -f my-rc.yaml
根据
kubectl create -f
查看资源对象get
get命令用于获取集群的一个或一些resource信息。resource包括集群节点、运行的pod，ReplicationController，service等。
查看所有Pod列表
kubectl get pods
查看rc和service列表
kubectl get rc,service
一般情况下使用时，需要你加入namespace来确定在哪个命名空间下查找
查看safety空间下所有pod在哪个节点上：
kubectl get pods -o wide -n safety
描述资源对象describe
describe类似于get，同样用于获取resource的相关信息。不同的是，get获得的是更详细的resource个性的详细信息，describe获得的是resource集群相关的信息。describe命令同get类似，但是describe不支持-o选项，对于同一类型resource，describe输出的信息格式，内容域相同。
显示Node的详细信息
kubectl describe nodes
显示Pod的详细信息
kubectl describe pods/
显示由RC管理的Pod的信息
kubectl describe pods
更新替换资源replace
replace命令用于对已有资源进行更新、替换。如前面create中创建的nginx，当我们需要更新resource的一些属性的时候，比如修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令。
注：名字不能被更新。另外，如果是更新label，原有标签的pod将会与更新label后的rc断开联系，有新label的rc将会创建指定副本数的新的pod，但是默认并不会删除原来的pod。所以此时如果使用get po将会发现pod数翻倍，进一步check会发现原来的pod已经不会被新rc控制，此处只介绍命令不详谈此问题，好奇者可自行实验。
kubectl replace -f rc-nginx.yaml
修复资源patch
如果一个容器已经在运行，这时需要对一些容器属性进行修改，又不想删除容器，或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时，直接对容器进行修改的方式，就是patch命令。
如前面创建pod的label是app=nginx-2，如果在运行过程中，需要把其label改为app=nginx-3，这patch命令如下：
kubectl patch pod rc-nginx-2-kpiqt -p '{"metadata":{"labels":{"app":"nginx-3"}}}'
删除资源对象delete
根据resource名或label删除resource。
基于Pod.yaml定义的名称删除Pod
kubectl delete -f pod.yaml
删除所有包含某个label的Pod和service
kubectl delete pods,services -l name=
删除所有Pod
kubectl delete pods --all
执行容器的命令exec
exec命令同样类似于docker的exec命令，为在一个已经运行的容器中执行一条shell命令，如果一个pod容器中，有多个容器，需要使用-c选项指定容器。
执行Pod的data命令，默认是用Pod中的第一个容器执行
kubectl exec data
指定Pod中某个容器执行data命令
kubectl exec -c data
通过bash获得Pod中某个容器的TTY，相当于登录容器
kubectl exec -it -c bash
6.Pod的扩容与缩容scale
scale用于程序在负载加重或缩小时副本进行扩容或缩小，如前面创建的nginx有两个副本，可以轻松的使用scale命令对副本数进行扩展或缩小。
执行扩容缩容Pod的操作
kubectl scale rc redis --replicas=3
我们需要确认的是在rc配置文件中定义的replicas数量，当我们执行上述命令的结果大于replicas的数量时，则我们执行的命令相当于扩容操作，反之相反，可以理解为我们填写的数量是我们需要的Pod数量。需要注意的是，当我们需要进行永久性扩容时，不要忘记修改rc配置文件中的replicas数量。
7.Pod的滚动升级rolling-update
rolling-update是一个非常重要的命令，对于已经部署并且正在运行的业务，rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod，等新pod完全起来后删除一个旧的pod，然后再起一个新的pod替换旧的pod，直到替换掉所有的pod。
执行滚动升级操作
kubectl rolling-update redis -f redis-rc.update.yaml
需要注意的是当我们执行rolling-update命令前需要准备好新的RC配置文件以及ConfigMap配置文件，RC配置文件中需要指定升级后需要使用的镜像名称，或者可以使用kubeclt rolling-update redis --image=redis-2.0直接指定镜像名称的方式直接升级。
日志logs
logs命令用于显示pod运行中，容器内程序输出到标准输出的内容。跟docker的logs命令类似。如果要获得tail -f 的方式，也可以使用-f选项。
kubectl logs rc-nginx-2-kpiqt
标签label
为kubernetes集群的resource打标签，如前面实例中提到的为rc打标签对rc分组。还可以对nodes打标签，这样在编排容器时，可以为容器指定nodeSelector将容器调度到指定lable的机器上，如如果集群中有IO密集型，计算密集型的机器分组，可以将不同的机器打上不同标签，然后将不同特征的容器调度到不同分组上。
在1.2之前的版本中，使用kubectl get nodes则可以列出所有节点的信息，包括节点标签，1.2版本中不再列出节点的标签信息，如果需要查看节点被打了哪些标签，需要使用describe查看节点的信息。
| 英文 简写 |
|---|
| clusters (仅对federation apiservers有效) |
| componentstatuses (缩写 cs) |
| configmaps (缩写 cm) |
| daemonsets (缩写 ds) |
| deployments (缩写 deploy) |
| endpoints (缩写 ep) |
| events (缩写 ev) |
| horizontalpodautoscalers (缩写 hpa) |
| ingresses (缩写 ing) |
| jobs |
| limitranges (缩写 limits) |
| namespaces (缩写 ns) |
| networkpolicies |
| nodes (缩写 no) |
| persistentvolumeclaims (缩写 pvc) |
| persistentvolumes (缩写 pv) |
| pods (缩写 po) |
| podsecuritypolicies (缩写 psp) |
| podtemplates |
| replicasets (缩写 rs) |
| replicationcontrollers (缩写 rc) |
| resourcequotas (缩写 quota) |
| secrets |
| serviceaccounts (缩写 sa) |
| services (缩写 svc) |
| statefulsets |
| storageclasses |
| thirdpartyresources |
kubectl edit
使用默认编辑器 编辑服务器上定义的资源。
使用命令行工具获取的任何资源都可以使用edit命令编辑。edit命令会打开使用KUBE_EDITOR，GIT_EDITOR 或者EDITOR环境变量定义的编辑器，可以同时编辑多个资源，但所编辑过的资源只会一次性提交。edit除命令参数外还接受文件名形式。
文件默认输出格式为YAML。要以JSON格式编辑，请指定“-o json”选项。
如果在更新资源时报错，将会在磁盘上创建一个临时文件来记录。在更新资源时最常见的错误是几个用户同时使用编辑器更改服务器上资源，发生这种情况，你需要将你的更改应用到最新版本的资源上，或者更新保存的临时副本。
示例
编辑名为’docker-registry’的service：
kubectl edit svc/docker-registry
使用替代的编辑器
KUBE_EDITOR="nano"
kubectl edit svc/docker-registry
编辑名为“myjob”的service，输出JSON格式 V1 API版本
kubectl edit job.v1.batch/myjob -o json
以YAML格式输出编辑deployment“mydeployment”，并将修改的配置保存在annotation中：
kubectl edit deployment/mydeployment -o yaml --save-config
Flags
| Name | Shorthand | Default | Usage |
|---|---|---|---|
| filename | f | [] | Filename, directory, or URL to files to use to edit the resource |
| include-extended-apis | true | If true, include definitions of new APIs via calls to the API server. [default true] | |
| output | o | yaml | Output format. One of: yaml |
| record | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | |
| recursive | R | false | Process the directory used in -f, --filename recursively. Useful when you want to manage related manifests organized within the same directory. |
| save-config | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | |
| schema-cache-dir | ~/.kube/schema | If non-empty, load/store cached API schemas in this directory, default is ‘$HOME/.kube/schema’ | |
| validate | true | If true, use a schema to validate the input before sending it | |
| windows-line-endings | false | Use Windows line-ending |
kubectl 获取资源属性
例如获取 pod的ip
kubectl -n naftis get pod -l app=naftis-ui -o jsonpath='{.items[0].status.podIP}'
其中我们通过-l app=naftis-ui 匹配pod，在jsonpath中指定要获取的资源属性
kubectl debug
部署集群代理
kubectl apply -f https://raw.githubusercontent.com/aylei/kubectl-debug/master/scripts/agent_daemonset.yml
安装客户端插件
# Linux
curl -Lo kubectl-debug https://github.com/aylei/kubectl-debug/releases/download/0.0.1/kubectl-debug_0.0.1_linux-amd64
# MacOS
curl -Lo kubectl-debug https://github.com/aylei/kubectl-debug/releases/download/0.0.1/kubectl-debug_0.0.1_macos-amd64
chmod +x ./kubectl-debug
mv kubectdl-debug /usr/local/bin/
添加客户端配置文件~/.kube/debug-config:
agent_port: 10027
# 可以使用自己的镜像
image: nicolaka/netshoot:latest
command:
- '/bin/bash'
- '-l'
配一个Dockerfile，可以自己构建debug镜像
# docker build -t luanpeng/lp:debug .
FROM ubuntu:18.04
RUN apt update && \
apt install -y python3.6-dev python3-pip openjdk-8-jdk ca-certificates-java ant ntpdate curl iputils-ping net-tools wget tcpdump iftop htop jq unzip zip sqlline iptables telnet vim jmeter && \
ln -s /usr/bin/python3.6 /usr/bin/python && \
ln -s /usr/bin/pip3 /usr/bin/pip && \
pip install aiohttp pika requests ray uvloop asyncio gunicorn && \
rm -rf /root/.cache && \
rm -rf /var/lib/apt/lists/* && \
apt clean
具体到实现上，一条 kubectl debug命令背后是这样的：
步骤分别是：
插件查询 ApiServer：demo-pod 是否存在，所在节点是什么
ApiServer 返回 demo-pod 所在所在节点
插件请求在目标节点上创建 Debug Agent Pod
Kubelet 创建 Debug Agent Pod
插件发现 Debug Agent 已经 Ready，发起 debug 请求（长连接）
Debug Agent 收到 debug 请求，创建 Debug 容器并加入目标容器的各个 Namespace 中，创建完成后，与 Debug 容器的 tty 建立连接
接下来，客户端就可以开始通过 5，6 这两个连接开始 debug 操作。操作结束后，Debug Agent 清理 Debug 容器，插件清理 Debug Agent，一次 Debug 完成。
kubectl 同时管理多个集群
如果我们有多个集群，那我们就有多个config文件。如果切换需要替换config文件，这比较麻烦，我们可以在一个config文件里面把多个集群配置在一起。
比如我们有两个config文件，分别如下
current-context: "contexts1"
apiVersion: v1
kind: Config
clusters:
- name: "cluster1"
cluster:
server: "xxxxxxxxxxxxxxxxx"
api-version: v1
certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
users:
- name: "user1"
user:
token: "xxxxxxxxxxxxxxxx"
contexts:
- name: "contexts1"
context:
user: "user1"
cluster: "cluster1"
current-context: "contexts2"
apiVersion: v1
kind: Config
clusters:
- name: "cluster2"
cluster:
server: "xxxxxxxxxxxxxxxxx"
api-version: v1
certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
users:
- name: "user2"
user:
token: "xxxxxxxxxxxxxxxx"
contexts:
- name: "contexts2"
context:
user: "user2"
cluster: "cluster2"
我们可以手动将两个文件合并成一个
current-context: "contexts1"
apiVersion: v1
kind: Config
clusters:
- name: "cluster1"
cluster:
server: "xxxxxxxxxxxxxxxxx"
api-version: v1
certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
- name: "cluster2"
cluster:
server: "xxxxxxxxxxxxxxxxx"
api-version: v1
certificate-authority-data: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
users:
- name: "user1"
user:
token: "xxxxxxxxxxxxxxxx"
- name: "user2"
user:
token: "xxxxxxxxxxxxxxxx"
contexts:
- name: "contexts1"
context:
user: "user1"
cluster: "cluster1"
- name: "contexts2"
context:
user: "user2"
cluster: "cluster2"
这样我们就可以通过命令切换集群了。
kubectl config use-context contexts2