k8s集群管理----kubectl命令

1. kubectl

• kubectl的命令

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进入维护模式。

2. kubectl命令格式

• 显示Pod的更多信息

kubectl get pod <pod-name> -o wide

• 以yaml文件显示pod的详细信息

kubectl get pod <pod-name> -o yaml

• 创建资源对象

#kubectl命令用于根据文件或输入创建集群resource。如果已经定义了相应resource的yaml或son文件，根据yaml配置文件一次性创建service和rc
kubectl create -f my-service -f my-rc.yaml
#具体的语法格式
kubectl create -f yaml文件

• 查看资源对象

#get命令用于获取集群的一个或一些resource信息。resource包括集群节点、运行的pod，ReplicationController，service等。
#查看所有pod列表
kubectl get pods
#查看rc和service列表
kubectl get rc,service
#一般都是结合namespace查看
kubectl get pods -o wide -n namespace

• 描述资源对象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

• pod的扩容与缩容scale

##scale用于程序在负载加重或缩小时副本进行扩容或缩小，如前面创建的nginx有两个副本，可以轻松的使用scale命令对副本数进行扩展或缩小。
##执行扩容缩容Pod的操作
kubectl scale rc redis --replicas=3
##我们需要确认的是在rc配置文件中定义的replicas数量，当我们执行上述命令的结果大于replicas的数量时，则我们执行的命令相当于扩容操作，反之相反，可以理解为我们填写的数量是我们需要的Pod数量。需要注意的是，当我们需要进行永久性扩容时，不要忘记修改rc配置文件中的replicas数量。

• 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	[]	要用于编辑资源的文件的文件名、目录或URL
include-extended-apis		true	如果为真，则通过调用API服务器来包含新API的定义。(默认正确)
output	o	yaml	输出格式之一:yaml
record		false	在资源注释中记录当前的kubectl命令。如果设置为false，则不记录命令。如果设置为true，则记录命令。如果未设置，则默认为仅在已有注释值的情况下更新现有注释值。
recursive	R	false	递归处理-f，–filename中使用的目录。当您希望管理在同一目录中组织的相关清单时，此功能非常有用。
save-config		false	如果为真，则当前对象的配置将保存在其注释中。否则，注释将保持不变。当您希望将来在这个对象上执行kubectl apply时，这个标志非常有用。
schema-cache-dir		~/.kube/schema	如果非空，在这个目录中加载/存储缓存的API模式，默认是’ $HOME/.kube/schema ’
validate		true	如果为真，请在发送输入之前使用模式验证输入
windows-line-endings		false	使用Windows行结束符

• 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 完成。