kubectl命令大全

kubectl 安装

参考https://blog.csdn.net/luanpeng825485697/article/details/80862581 文章中kubectl部分

linux命令行经过tab键自动补全的方式

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashr

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 <pod-name> -o wide

以yaml格式显示Pod的详细信息

kubectl get pod <pod-name> -o yaml

kubectl 操做示例

建立资源对象create

kubectl命令用于根据文件或输入建立集群resource。若是已经定义了相应resource的yaml或son文件

根据yaml配置文件一次性建立service和rc

kubectl create -f my-service.yaml -f my-rc.yaml

根据<directory>目录下全部.yaml、.yml、.json文件的定义进行建立操做

kubectl create -f <directory>

查看资源对象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 <node-name>

显示Pod的详细信息

kubectl describe pods/<pod-name>

显示由RC管理的Pod的信息

kubectl describe pods <rc-name>

更新替换资源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=<label-name>

删除全部Pod

kubectl delete pods --all

执行容器的命令exec

exec命令一样相似于docker的exec命令，为在一个已经运行的容器中执行一条shell命令，若是一个pod容器中，有多个容器，须要使用-c选项指定容器。

执行Pod的data命令，默认是用Pod中的第一个容器执行

kubectl exec <pod-name> data

指定Pod中某个容器执行data命令

kubectl exec <pod-name> -c <container-name> data

经过bash得到Pod中某个容器的TTY，至关于登陆容器

kubectl exec -it <pod-name> -c <container-name> 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

 

 

参考：

https://blog.csdn.net/luanpeng825485697/article/details/80874741