Kubernetes API是管理各种资源对象的唯一入口 , 它提供了一个 RESTful风格的CRUD（Create、Read、Update和Delete)接口用于查询和修改集群状态 , 并将结果存储在集群状态存储系统etcd中。事实上 , API Server也是用于更新etcd中资源对象状态的唯一途径 , Kubernetes的其他所有组件和客户端都要通过它完成查询或修改操作 ,

任何RESTful风格API的核心概念都是“资源” , 资源可以根据其特性分组 , 每个组是同一类型资源的集合 , 即仅包含一种类型的资源 , 并且各资源间不存在顺序的概念 , 集合本身也是资源。对应于 Kubernetes中 , Pod、Deployment和Service等都是所谓的资源类型 , 它们由相应类型的对象集合而成。

kubectl的核心功能在于通过API Server操作Kubernetes的各种资源对象 , 它支持3种操作方式 , 其中直接命令式使用最为简便 , 是了解~集群管理的有效途径。

1. 资源管理操作

Kubernetes API资源管理的操作可简单归结为增、删、改、查这4 种 , kubectl提供了一系列子命令用于执行此类任务 , 例如create、 delete、patch、apply、replace、edit、get等。其中 , 有些命令必须基于资源清单进行 , 例如apply和replace命令 , 有些命令既可基于清单文件进行 , 也可实时作用于活动资源之上 , 例如create、get、 patch和delete等。 kubectl命令能够读取任何以.yaml、.yml或.json为后缀的文件 (可称为配置清单或配置文件 , 后文将不加区别地使用这两个术语)。在实践中 , 用户既可以为每个资源使用专用的清单文件 , 也可以将多个相关的资源(例如属于同一个应用或微服务)组织在同一个清单文件中。但在YAML格式的清单文件中 , 多个资源彼此间要使用“---”符号作为单独的一行进行资源分割 , 多个资源将以清单文件中定义的次序由create、apply等子命令调用。

kubectl的多数子命令支持使用-f选项指定使用的清单文件路径或 URL , 甚至直接指定存储有清单文件的目录 , 而该选项在同一命令中也可重复使用多次。若指定的目录路径存在子目录 , 也可按需同时使用 R选项以递归获取子目录中的配置清单。

支持在资源对象上使用标签和注解是Kubernetes的一大特色 , 它为资源管理机制增色不少 , 类似于delete和get之类的命令都能基于标签挑选目标对象 , 有些资源甚至必须依赖标签才能正常工作 , 例如 Service和Deployment等资源类型。子命令label用于管理资源标签 , 而管理资源注解的子命令是annotate。

就地更新(修改)现有的资源也是一种常见操作。apply命令通过比较资源在清单文件中的版本及前一次的版本执行更新操作 , 而不对未定义的属性产生额外作用。edit命令相当于先使用get命令获取资源配置 , 由用户通过交互式编辑器修改后再自动使用apply命令将其应用。patch命令基于JSON补丁、JSON合并补丁及策略合并补丁对资源进行就地更新操作。

2. kubectl 命令格式

如前所述 , kubectl是最常用的客户端工具之一 , 它提供了基于命令行访问Kubernetes API的简洁方式 , 支持对各种类型资源的CRUD操作 , 能够满足针对Kubernetes系统的绝大部分的操作需求。例如 , 需要创建资源对象时 , kubectl能够将资源清单内容以POST方式提交至API Server并接收其响应。本节将描述kubectl的基本功能和常用选项

kubectl特性丰富且功能强大 , 是Kubernetes管理员最常用的集群管理工具。其最基本的语法格式: kubectl [command] [TYPE] [NAME] [flags] , 其中各部分的简要说明如下

command: 对资源执行相应操作的子命令 , 例如get、create、 delete、run等 ;
TYPE : 要操作的资源类型 , 例如pods、services等 ; 类型名称大小写敏感 , 但支持使用单数、复数或简写格式。
NAME: 要操作的资源对象名称 , 大小写敏感 ; 省略时 , 则表示指定TYPE的所有资源对象 ; 同一类型的资源名称可于TYPE后同时给出多个 , 也可以直接使用TYPE/NAME的格式来为每个资源对象分别指定类型。
flags : 命令行选项 , 例如-s或--server等 ; 另外 , get等命令在输出时还有一个常用的标志-o 用于指定输出格式

2.1 `kubectl`子命令

apply：可以重复创建一个文件，如果文件内容相同，不发生改变，如果文件内容改变了，可以创建新的pod。

create：只能对相同文件名创建一次名称空间，如果继续对一个源文件进行修改后，就会提示报错信息。

基础命令(初级)
- create : 通过文件或标准输入创建资源
- expose : 基于RC 、Service、Deployment或Pod创建Service资源
- run : 在集群中以Pod形式运行指定的镜像
- set : 设置目标资源对象的特定属性
基础命令(中级)
- explain : 打印指定资源的内置文档
- get : 显示一个或多个资源
- edit : 编辑资源
- delete : 基于文件名、sdtin、资源或名字, 以及资源和选择器删除资源
部署命令
- rollout : 管理资源的滚动更新
- scale : 伸缩Deployment 、ReplicaSet 、RC或Job的规模
- autoscale : 对Deployment、ReplicaSet或RC进行自动伸缩
集群管理命令
- certificate : 配置数字证书资源
- cluser-info : 打印集群信息
- top : 打印资源(CPU/Memory/Storage)使用率
- cordon : 将指定node设置为不可用(unschedulable)状态
- uncordon : 将指定node设定为可用(schedulable)状态
- drain : 排空Node上的Pod 以进入维护模式
- taint : 为node声明为污点及标准行为
排除及调试命令
- descirbe : 显示指定资源或资源组的详细信息
- logs : 显示一个pod内某容器的日志
- attach : 附加中断至一个运行中的容器
- exec : 在容器中执行指定命令
- port-forward : 将本地的一个或多个端口转发至指定pod
- proxy : 创建能访问Kubernetes API Server的代理
- cp : 在容器间复制文件或目录
- auth : 打印授权信息
- debug : 创建调试会话以排除工作负载和节点的故障
- events : 列出所有事件
高级命令
- diff : 对比当前版本与即将应用的新版本的不同
- apply : 基于文件或stdin将配置应用于资源
- patch : 使用策略合并补丁更新资源字段
- replace : 基于文件或stdin替换一个资源
- wait : 等待一个或多个资源上的指定境况(condition)
- kustomize : 基于目录或URL构建kunstomization目标
设置命令
- label : 更新指定资源的label
- annotate : 更新资源的annotation , 为一个或多个资源添加注释
- completion : 输出指定的shell(例如bash)的补全码
其他命令
- api-resources : 打印API支持的资源类型
- api-versions : 以group/version格式打印服务器支持的API版本信息
- config : 配置kubeconfig文件的内容
- plugin : 运行命令行插件
- version : 打印kubernetes服务端和客户端的版本信息

2.2 kubectl 输出格式

kubectl get命令能够支持多种不同的输出格式 , 一些高级命令的格式甚至为用户提供了非常灵活的自定义输出机制 , 例如jsonpath、go-tempate和custom-columns等。

输出格式	格式说明
`-o wide`	以纯文本格式显示资源的附加信息
`-o name`	仅打印资源名称
`-o yaml`	以`YAML`格式化输出`API`对象信息
`-o json`	以`JSON`格式化输出`API`对象信息
`-o jsonpath`	以自定义`jsonpath`模板格式输出`API`对象信息
`-o go-template`	以自定义`go`模板格式输出`API`对象信息
`-o custom-columns`	自定义要输出的字段

此外 , kubectl还有许多通用选项 , 这个可以使用kubectl options命令获取。其中比较常用的选项如下所示。

-s或--server : 指定API Server的地址和端口。
--kubeconfig : 使用的kubeconfig配置文件路径 , 默认为 ~/.kube/config
-n或--namespace : 命令执行的目标名称空间。

2.3 资源类型

root@kubeadm-master1:~# kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                          NAMESPACED   KIND
bindings                                       v1                                  true         Binding
componentstatuses                 cs           v1                                  false        ComponentStatus
configmaps                        cm           v1                                  true         ConfigMap
endpoints                         ep           v1                                  true         Endpoints
events                            ev           v1                                  true         Event
limitranges                       limits       v1                                  true         LimitRange
namespaces                        ns           v1                                  false        Namespace
nodes                             no           v1                                  false        Node
persistentvolumeclaims            pvc          v1                                  true         PersistentVolumeClaim
persistentvolumes                 pv           v1                                  false        PersistentVolume
pods                              po           v1                                  true         Pod
podtemplates                                   v1                                  true         PodTemplate
replicationcontrollers            rc           v1                                  true         ReplicationController
resourcequotas                    quota        v1                                  true         ResourceQuota
secrets                                        v1                                  true         Secret
serviceaccounts                   sa           v1                                  true         ServiceAccount
services                          svc          v1                                  true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1     false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1     false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1             false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1           false        APIService
controllerrevisions                            apps/v1                             true         ControllerRevision
daemonsets                        ds           apps/v1                             true         DaemonSet
deployments                       deploy       apps/v1                             true         Deployment
replicasets                       rs           apps/v1                             true         ReplicaSet
statefulsets                      sts          apps/v1                             true         StatefulSet
selfsubjectreviews                             authentication.k8s.io/v1            false        SelfSubjectReview
tokenreviews                                   authentication.k8s.io/v1            false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io/v1             true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io/v1             false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io/v1             false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io/v1             false        SubjectAccessReview
horizontalpodautoscalers          hpa          autoscaling/v2                      true         HorizontalPodAutoscaler
cronjobs                          cj           batch/v1                            true         CronJob
jobs                                           batch/v1                            true         Job
certificatesigningrequests        csr          certificates.k8s.io/v1              false        CertificateSigningRequest
ingressclassparameterses                       configuration.konghq.com/v1alpha1   true         IngressClassParameters
kongclusterplugins                kcp          configuration.konghq.com/v1         false        KongClusterPlugin
kongconsumergroups                kcg          configuration.konghq.com/v1beta1    true         KongConsumerGroup
kongconsumers                     kc           configuration.konghq.com/v1         true         KongConsumer
kongingresses                     ki           configuration.konghq.com/v1         true         KongIngress
konglicenses                      kl           configuration.konghq.com/v1alpha1   false        KongLicense
kongplugins                       kp           configuration.konghq.com/v1         true         KongPlugin
kongupstreampolicies              kup          configuration.konghq.com/v1beta1    true         KongUpstreamPolicy
kongvaults                        kv           configuration.konghq.com/v1alpha1   false        KongVault
tcpingresses                                   configuration.konghq.com/v1beta1    true         TCPIngress
udpingresses                                   configuration.konghq.com/v1beta1    true         UDPIngress
leases                                         coordination.k8s.io/v1              true         Lease
endpointslices                                 discovery.k8s.io/v1                 true         EndpointSlice
events                            ev           events.k8s.io/v1                    true         Event
flowschemas                                    flowcontrol.apiserver.k8s.io/v1     false        FlowSchema
prioritylevelconfigurations                    flowcontrol.apiserver.k8s.io/v1     false        PriorityLevelConfiguration
ingressclasses                                 networking.k8s.io/v1                false        IngressClass
ingresses                         ing          networking.k8s.io/v1                true         Ingress
networkpolicies                   netpol       networking.k8s.io/v1                true         NetworkPolicy
runtimeclasses                                 node.k8s.io/v1                      false        RuntimeClass
poddisruptionbudgets              pdb          policy/v1                           true         PodDisruptionBudget
clusterrolebindings                            rbac.authorization.k8s.io/v1        false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io/v1        false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io/v1        true         RoleBinding
roles                                          rbac.authorization.k8s.io/v1        true         Role
priorityclasses                   pc           scheduling.k8s.io/v1                false        PriorityClass
csidrivers                                     storage.k8s.io/v1                   false        CSIDriver
csinodes                                       storage.k8s.io/v1                   false        CSINode
csistoragecapacities                           storage.k8s.io/v1                   true         CSIStorageCapacity
storageclasses                    sc           storage.k8s.io/v1                   false        StorageClass
volumeattachments                              storage.k8s.io/v1                   false        VolumeAttachment

2.4 具体命令详解

2.4.1 run

在pod中创建并运行一个特定的镜像。这里需要说明这里命令以前的版本是快速创建一个 Deployment , 该 Deployment 管理一个或多个 Pod , 每个 Pod 都运行指定的容器镜像。新版本直接创建一个pod, 并在pod中创建一个镜像。而不会再创建Deployment。因此新版本的参数有一些变化, 例如无法使用--replicas：指定副本数量

 kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...] [options]

选项

--annotations=[] :应用于pod的注释。
--image : 指定容器运行镜像
-l, --labels='': 指定标签
--expose=false : 如果为true , 则创建与pod关联的ClusterIP services。需要 --port参数
--port='' :此容器的公开容器端口
--restart='Always': 设置pod的重启策略。always ,OnFailure ,Never。
--env=[] : 要在容器中设置的环境变量。
--rm=false: : 设置为true时, 退出容器时直接删除。只有进入到容器才会生效。和--attch或'-i/--stdin'参数一起使用
-i,--stdin=false : 保持pod中容器上的stdin处于打开状态 , 即使没有附加任何内容。
--attach=false : 如果为true , 请等待Pod开始运行 , 然后连接到Pod , 如同“kubectl attach…”被调用。默认值为false , 除非设置了'-i/--stdin' , 在这种情况下 , 默认值为true。使用“--restart=Never”返回容器进程的退出代码。

示例

# 启动一个nignx pod
kubectl run nginx --image=nginx
  
# Start a hazelcast pod and let the container expose port 5701
kubectl run hazelcast --image=hazelcast/hazelcast --port=5701
  
# Start a hazelcast pod and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container
kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"
  
# Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container
kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"
  
# Dry run; print the corresponding API objects without creating them
kubectl run nginx --image=nginx --dry-run=client
  
# Start a nginx pod, but overload the spec with a partial set of values parsed from JSON
kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'
  
# Start a busybox pod and keep it in the foreground, don't restart it if it exits
kubectl run -i -t busybox --image=busybox --restart=Never
  
# Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that command
kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>
  
# Start the nginx pod using a different command and custom arguments
kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

2.4.2 delete

按文件名、stdin、资源和名称或按资源和标签选择器删除资源。

支持JSON和YAML格式文件。可以只指定一种类型的参数 : 文件名、资源名称或label选择器。

语法

 kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)]) [options]

选项
- --all=false : 删除所有资源。删除指定资源类型的命名空间中的所有资源。
- -A,--all-namespaces=false : 如果存在 , 列出所有命名空间中请求的对象。可以使用--namespace指定显示具体namespace中的内容
- --field-selector='' : 要过滤的选择器(selector)(字段查询) , 支持'=' , '=='和'!='。(示例 --field-selector key1 = value1,key2 = value2)。服务器只支持每种类型有限数量的字段查询。
- -f, --filename=[] : 包含要删除的资源。
- --force=false : 设置为true, 则强制删除对应资源
- --grace-period=-1 : 给资源的以秒为单位的正常终止时间。如果是负数则忽略。设置为1立即关闭。只能在--force为true(强制删除)时设置为0。
- --ignore-not-found=false : 对resource not foune当初成功删除。当设置--all 默认为true。
- -i ,--interactive=false : 如果设置为true , 则需要用户确认才能删除
- -o, --output='' : 设置output模式。设置为-o name 则显示删除的资源名称(resource/name)
- -l, --selector='' : 选择器(标签查询)筛选 , 支持'=' , '=='和'!='。(示例: - l key1 = value1, key2 = value2)。匹配对象必须满足所有指定的标签约束。
- --now=false : 如果设置为true ,则尽快删除对应资源

示例


# Delete a pod using the type and name specified in pod.json
kubectl delete -f ./pod.json
  
# Delete resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml
kubectl delete -k dir
  
# Delete resources from all files that end with '.json'
kubectl delete -f '*.json'
  
# Delete a pod based on the type and name in the JSON passed into stdin
cat pod.json | kubectl delete -f -
  
# Delete pods and services with same names "baz" and "foo"
kubectl delete pod,service baz foo
  
# Delete pods and services with label name=myLabel
kubectl delete pods,services -l name=myLabel
  
# Delete a pod with minimal delay
kubectl delete pod foo --now
  
# Force delete a pod on a dead node
kubectl delete pod foo --force
  
# Delete all pods
 kubectl delete pods --all

2.4.3 expose

将资源暴露为新的Kubernetes Service。

指定deployment、service、replica set、replication controller或pod , 并使用该资源的选择器作为指定端口上新服务的选择器。deployment 或 replica set只有当其选择器可转换为service支持的选择器时 , 即当选择器仅包含matchLabels组件时才会作为暴露新的Service。

资源包括(不区分大小写)：pod(po) , service(svc) , replication controller(rc) , deployment(deploy) , replica set(rs)

语法

 kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [options]

常用选项
- --port=port : 指定service中暴露的端口。如果未指定 , 则直接指定开放容器开放的端口
- --protocol=TCP|UDP|SCTP : service指定的协议
- --target-port=number-or-name : 容器上的端口的名称或编号 , service应将通信定向到该端口
- --name=name : 创建新对象的名称
- --type=type : service的类型, ClusterIP ,NodePort,LoadBalancer, ExternalName。默认为ClusterIP

示例

Examples:
  #Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000
  kubectl expose rc nginx --port=80 --target-port=8000
  
  # Create a service for a replication controller identified by type and name specified in "nginx-controller.yaml", which serves on port 80 and connects to the containers on port 8000
  kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000
  
  # Create a service for a pod valid-pod, which serves on port 444 with the name "frontend"
  kubectl expose pod valid-pod --port=444 --name=frontend
  
  # Create a second service based on the above service, exposing the container port 8443 as port 443 with the name
"nginx-https"
  kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https
  
  # Create a service for a replicated streaming application on port 4100 balancing UDP traffic and named 'video-stream'.
  kubectl expose rc streamer --port=4100 --protocol=UDP --name=video-stream
  
  # Create a service for a replicated nginx using replica set, which serves on port 80 and connects to the containers on port 8000
  kubectl expose rs nginx --port=80 --target-port=8000
  
  # Create a service for an nginx deployment, which serves on port 80 and connects to the containers on port 8000
  kubectl expose deployment nginx --port=80 --target-port=8000

2.4.4 scale

扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量。

scale也可以指定多个前提条件 , 如：当前副本数量或 --resource-version , 进行伸缩比例设置前 , 系统会先验证前提条件是否成立。

语法

kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME) [options]

选项
- --all=false : 选择指定资源类型命名空间下的所有资源
- --current-replicas=-1 : 默认只有当前pod的数量为指定数量时, 才会进行后续的扩容和缩容。-1(默认)表示没有条件。
- -f, --filename=[] : 标识要设置新大小的资源的文件的文件名、目录或URL
- --replicas=0 : 新的所需的副本数量。
- -l,--selector='' : 匹配对象必须满足所有指定的标签约束。

示例

Examples:
  # Scale a replica set named 'foo' to 3
  kubectl scale --replicas=3 rs/foo
  
  # Scale a resource identified by type and name specified in "foo.yaml" to 3
  kubectl scale --replicas=3 -f foo.yaml
  
  # If the deployment named mysql's current size is 2, scale mysql to 3
  kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
  
  # Scale multiple replication controllers
  kubectl scale --replicas=5 rc/example1 rc/example2 rc/example3
  
  # Scale stateful set named 'web' to 3
  kubectl scale --replicas=3 statefulset/web

2.4.5 set

配置应用资源。

使用这些命令能帮你更改现有应用资源一些信息。

语法 : kubectl set SUBCOMMAND [options]
子命令：image、resources、selector、subject、serviceaccount、env

set image

语法 : kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N [options]
更新现有的资源对象的容器镜像。
可使用资源对象包括(不区分大小写) : pod (po)、replicationcontroller (rc)、deployment (deploy)、daemonset (ds)、job、replicaset (rs)

示例

# Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
  
# Update all deployments' and rc's nginx container's image to 'nginx:1.9.1'
kubectl set image deployments,rc nginx=nginx:1.9.1 --all
  
# Update image of all containers of daemonset abc to 'nginx:1.9.1'
kubectl set image daemonset abc *=nginx:1.9.1
  
# Print result (in yaml format) of updating nginx container image from local file, without hitting the server
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

[root@master ~]# kubectl set image deployment myapp myapp=ikubernetes/myapp:v2
deployment.extensions/myapp image updated
[root@master ~]# kubectl rollout status deployment myapp  #动态显示版本升级过程
---因为版本升级 , 所以pod都是新建的 , 名字都改变了
[root@master ~]# kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
client                        1/1       Running   0          3h
myapp-74c94dcb8c-d5fgk        1/1       Running   0          55s
myapp-74c94dcb8c-f2ntn        1/1       Running   0          21s
myapp-74c94dcb8c-ht9v7        1/1       Running   0          38s
---验证 , 版本升级成功
[root@master ~]# curl 10.104.205.158
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

set resources
为定义pod模板的任何资源指定计算资源需求(CPU、内存)。如果成功地调度了一个pod , 它就可以保证所请求的资源量 , 但可能会达到指定的限制。
对于每个计算资源 , 如果指定了限制并且省略了请求 , 则请求将默认为该限制。
可能的资源包括(不区分大小写):使用"kubectl api-resources"获取支持的资源的完整列表。
选项
- -c, --containers='*' : 指定选择的pod模板中的容器名称，默认为pod中的所有容器 , 可以使用通配符
- --dry-run='none' : “none”、“server”或“client”。如果是client策略，则只打印要发送的对象，而不发送对象。如果是server策略，则提交服务器端请求而不创建持久化资源。
- -f, --filename=[] : 标识要从服务器获取的资源的文件的文件名、目录或URL。
- --limits='' : 这个容器的资源需求请求。例如，“cpu=100m，memory=256Mi”。请注意，服务器端组件可能会根据服务器配置(例如限制范围)分配请求。
- --requests='' : 这个容器的资源需求请求。例如，“cpu=100m，memory=256Mi”。请注意，服务器端组件可能会根据服务器配置(例如限制范围)分配请求。
- -l,--selector='' : 匹配对象必须满足所有指定的标签约束
- -o,--output='' : 输出格式。(json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath，jsonpath-as-json , jsonpath-file)
```
Examples:
  # Set a deployments nginx container cpu limits to "200m" and memory to "512Mi"
  kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
  
  # Set the resource request and limits for all containers in nginx
  kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi
  
  # Remove the resource requests for resources on containers in nginx
  kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0
  
  # Print the result (in yaml format) of updating nginx container limits from a local, without hitting the server
  kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml
```
set selector
在资源上设置选择器。请注意，如果资源在调用'set selector'之前有一个选择器，那么新的选择器将覆盖旧的选择器。
选择器必须以字母或数字开头，可以包含字母、数字、“-”、“.”和“_”，长度不超过63个字符。
如果指定了--resource-version，则更新将使用此资源版本，否则将使用现有的资源版本。注意:目前选择器只能在Service对象上设置。
```
Examples:
  # Set the labels and selector before creating a deployment/service pair
  kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
  kubectl create deployment my-dep -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f -
```

2.4.6 rollout

对资源进行管理

可用资源包括：deployments、daemonsets
语法 : kubectl rollout SUBCOMMAND [options]

子命令：history（查看历史版本）、pause（暂停资源）、resume（恢复暂停资源）、status（查看资源状态）、undo（回滚版本）

Examples:
  # View the rollout history of a deployment
  kubectl rollout history deployment/abc
  
  # View the details of daemonset revision 3
  kubectl rollout history daemonset/abc --revision=3

  # Mark the nginx deployment as paused
  # Any current state of the deployment will continue its function; new updates
  # to the deployment will not have an effect as long as the deployment is paused
  kubectl rollout pause deployment/nginx

  # Resume an already paused deployment
  kubectl rollout resume deployment/nginx

  # Watch the rollout status of a deployment
  kubectl rollout status deployment/nginx

  # Roll back to the previous deployment
  kubectl rollout undo deployment/abc
  
  # Roll back to daemonset revision 3
  kubectl rollout undo daemonset/abc --to-revision=3
  
  # Roll back to the previous deployment with dry-run
  kubectl rollout undo --dry-run=server deployment/abc

2.4.7edit

使用默认编辑器，编辑服务器上定义的资源。
使用命令行工具获取的任何资源都可以使用edit命令编辑。edit命令会打开使用KUBE_EDITOR，GIT_EDITOR 或者EDITOR环境变量定义的编辑器，可以同时编辑多个资源，但所编辑过的资源只会一次性提交。edit除命令参数外还接受文件名形式。
文件默认输出格式为YAML。要以JSON格式编辑，请指定“-o json”选项。
如果在更新资源时报错，将会在磁盘上创建一个临时文件来记录。在更新资源时最常见的错误是几个用户同时使用编辑器更改服务器上资源，发生这种情况，你需要将你的更改应用到最新版本的资源上，或者更新保存的临时副本。

Examples:
  # Edit the service named 'registry'
  kubectl edit svc/registry
  
  # Use an alternative editor
  KUBE_EDITOR="nano" kubectl edit svc/registry
  
  # Edit the job 'myjob' in JSON using the v1 API format
  kubectl edit job.v1.batch/myjob -o json
  
  # Edit the deployment 'mydeployment' in YAML and save the modified config in its annotation
  kubectl edit deployment/mydeployment -o yaml --save-config
  
  # Edit the 'status' subresource for the 'mydeployment' deployment
  kubectl edit deployment mydeployment --subresource='status'

2.5 kubectl常用示例

查看类命令

# 获取节点和服务版本信息
kubectl get nodes
# 获取节点和服务版本信息，并查看附加信息
kubectl get nodes -o wide
 
# 获取pod信息，默认是default名称空间
kubectl get pod
# 获取pod信息，默认是default名称空间，并查看附加信息【如：pod的IP及在哪个节点运行】
kubectl get pod -o wide
# 获取指定名称空间的pod
kubectl get pod -n kube-system
# 获取指定名称空间中的指定pod
kubectl get pod -n kube-system podName
# 获取所有名称空间的pod
kubectl get pod -A 
# 查看pod的详细信息，以yaml格式或json格式显示
kubectl get pods -o yaml
kubectl get pods -o json
 
# 查看pod的标签信息
kubectl get pod -A --show-labels 
# 根据Selector（label query）来查询pod
kubectl get pod -A --selector="k8s-app=kube-dns"

# 查看运行pod的环境变量
kubectl exec podName env
# 查看指定pod的日志
kubectl logs -f --tail 500 -n kube-system kube-apiserver-k8s-master

# 查看所有名称空间的service信息
kubectl get svc -A
# 查看指定名称空间的service信息
kubectl get svc -n kube-system
 
# 查看componentstatuses信息
kubectl get cs
# 查看所有configmaps信息
kubectl get cm -A
# 查看所有serviceaccounts信息
kubectl get sa -A
# 查看所有daemonsets信息
kubectl get ds -A
# 查看所有deployments信息
kubectl get deploy -A
# 查看所有replicasets信息
kubectl get rs -A
# 查看所有statefulsets信息
kubectl get sts -A
# 查看所有jobs信息
kubectl get jobs -A
# 查看所有ingresses信息
kubectl get ing -A
# 查看有哪些名称空间
kubectl get ns
  
# 查看pod的描述信息
kubectl describe pod podName
kubectl describe pod -n kube-system kube-apiserver-k8s-master  
# 查看指定名称空间中指定deploy的描述信息
kubectl describe deploy -n kube-system coredns

# 查看node或pod的资源使用情况
# 需要heapster 或metrics-server支持
kubectl top node
kubectl top pod 
 
# 查看集群信息
kubectl cluster-info   或  kubectl cluster-info dump
# 查看各组件信息【172.16.1.110为master机器】
kubectl -s https://172.16.1.110:6443 get componentstatuses

操作类命令

# 创建资源
kubectl create -f xxx.yaml
# 应用资源
kubectl apply -f xxx.yaml
# 应用资源，该目录下的所有 .yaml, .yml, 或 .json 文件都会被使用
kubectl apply -f <directory>
# 创建test名称空间
kubectl create namespace test

# 删除资源
kubectl delete -f xxx.yaml
kubectl delete -f <directory>
# 删除指定的pod
kubectl delete pod podName
# 删除指定名称空间的指定pod
kubectl delete pod -n test podName
# 删除其他资源
kubectl delete svc svcName
kubectl delete deploy deployName
kubectl delete ns nsName
 # 强制删除
kubectl delete pod podName -n nsName --grace-period=0 --force
kubectl delete pod podName -n nsName --grace-period=1
kubectl delete pod podName -n nsName --now

# 编辑资源
kubectl edit pod podName

进阶命令操作

# kubectl exec：进入pod启动的容器
kubectl exec -it podName -n nsName /bin/sh    #进入容器
kubectl exec -it podName -n nsName /bin/bash  #进入容器

# kubectl label：添加label值
kubectl label nodes k8s-node01 zone=north  #为指定节点添加标签 
kubectl label nodes k8s-node01 zone-       #为指定节点删除标签
kubectl label pod podName -n nsName role-name=test    #为指定pod添加标签
kubectl label pod podName -n nsName role-name=dev --overwrite  #修改lable标签值
kubectl label pod podName -n nsName role-name-        #删除lable标签
 
# kubectl滚动升级； 通过 kubectl apply -f myapp-deployment-v1.yaml 启动deploy
kubectl apply -f myapp-deployment-v2.yaml     #通过配置文件滚动升级
kubectl set image deploy/myapp-deployment myapp="registry.cn-beijing.aliyuncs.com/google_registry/myapp:v3"   #通过命令滚动升级
kubectl rollout undo deploy/myapp-deployment 或者 kubectl rollout undo deploy myapp-deployment    #pod回滚到前一个版本
kubectl rollout undo deploy/myapp-deployment --to-revision=2  #回滚到指定历史版本
 
# kubectl scale：动态伸缩
kubectl scale deploy myapp-deployment --replicas=5  # 动态伸缩
kubectl scale --replicas=8 -f myapp-deployment-v2.yaml  #动态伸缩【根据资源类型和名称伸缩，其他配置「如：镜像版本不同」不生效】

上面滚动更新和动态伸缩涉及的deploy的yaml文件

 1 [root@k8s-master deploy]# cat myapp-deployment-v1.yaml 
 2 apiVersion: apps/v1
 3 kind: Deployment
 4 metadata:
 5   name: myapp-deployment
 6   labels:
 7     app: myapp
 8 spec:
 9   replicas: 10
10   # 重点关注该字段
11   selector:
12     matchLabels:
13       app: myapp
14   template:
15     metadata:
16       labels:
17         app: myapp
18     spec:
19       containers:
20       - name: myapp
21         image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
22         ports:
23         - containerPort: 80
24 
25 [root@k8s-master deploy]# 
26 [root@k8s-master deploy]# cat myapp-deployment-v2.yaml 
27 apiVersion: apps/v1
28 kind: Deployment
29 metadata:
30   name: myapp-deployment
31   labels:
32     app: myapp
33 spec:
34   replicas: 10
35   # 重点关注该字段
36   selector:
37     matchLabels:
38       app: myapp
39   template:
40     metadata:
41       labels:
42         app: myapp
43     spec:
44       containers:
45       - name: myapp
46         image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v2
47         ports:
48         - containerPort: 80

3. kubectl命令常用操作示例

为了便于读者快速了解kubectl命令及Kubernetes API资源管理的基本操作 , 这里给出几个使用示例以说明其基本使用方法 , 更多的使用方法会在后面章节随着需要再展开说明。

3.1 创建资源对象

Kubernetes系统的大部分资源都隶属于名称空间级别 , 默认的名称空间为default , 若需要获取指定Namespace对象中的资源对象的信息 , 则需要使用-n或--namespace指明其名称。直接通过kubectl命令及相关的选项创建资源对象的方式即直接命令式操作。例如 , 在下面的命令中 , 第一条命令创建了名为dev的Namespace对象 , 后两条命令在dev名称空间中分别创建了名为demoapp的Deployment控制器资源对象和名为demoapp的Service资源对象。

root@kubeadm-master1:~# kubectl create namespace dev
namespace/dev created
root@kubeadm-master1:~# kubectl create deployment demoapp --image="ikubernetes/demoapp:v1.0" -n dev
deployment.apps/demoapp created
root@kubeadm-master1:~# kubectl create service clusterip demoapp --tcp=80 -n dev
service/demoapp created

Deployment和Service对象还分别有一个创建命令kubectl run和 kubectl expose , 但它们即将废弃。

若要直接运行一个自主式Pod对象 , 也可使用kubectl run命令实现。例如下面第一条命令创建了一个名为demoapp的Pod对象 , 内部容器由指定的镜像运行 , 而第二条命令创建的Pod对象则在前台改为运行由用户指定的命令 , 且退出后将被自动删除。

root@kubeadm-master1:~# kubectl run demoapp --image="ikubernetes/dmeoapp:v1.0" 
pod/demoapp created
root@kubeadm-master1:~# kubectl run demoapp-$RANDOM --image="ikubernetes/demoapp:v1.0" --rm -it   --command /bin/sh
If you don't see a command prompt, try pressing enter.
[root@demoapp-25119 /]# ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var

另外 , 我们也可以根据资源清单创建资源对象 , 即采用“命令式对象配置文件”管理方式。例如 , 假设存在定义了Deployment对象的 deployment-demoapp.yaml文件 , 以及定义了Service对象的service demoapp.yaml文件 , 使用kubectl create命令即可进行基于命令式对象配置文件的创建操作

kubectl create -f deployment-demoapp.yaml -f service-demoapp.yaml

甚至还可以将创建交由kubectl自行确定 , 用户只需要声明期望的状态 , 这种方式称为声明式对象配置。仍以deployment-demoapp.yaml和service-demoapp.yaml文件为例 , 使用kubectl apply命令即可实现声明式配置:

 kubectl apply -f deployment-demoapp.yaml -f service-demoapp.yaml

3.2 查看资源对象

运行着实际负载的Kubernetes系统上通常会存在多种资源对象 , 用户可分类列出感兴趣的资源对象及其相关的状态信息 , kubectl get 正是完成此类功能的命令。例如下面的命令能够列出系统上所有的 Namespace资源对象。

root@kubeadm-master1:~# kubectl get namespaces
NAME                   STATUS   AGE
default                Active   18h
dev                    Active   31m
kube-flannel           Active   16h
kube-node-lease        Active   18h
kube-public            Active   18h
kube-system            Active   18h
kubernetes-dashboard   Active   17h

我们也可以一次查看多个资源类别下的资源对象 , 例如 , 列出默认名称空间内的所有Pod和Service对象 , 并输出额外信息。可以使用如下形式的kubectl get命令实现

root@kubeadm-master1:~# kubectl get pods,services -o wide
NAME                READY   STATUS             RESTARTS   AGE   IP           NODE               NOMINATED NODE   READINESS GATES
pod/demoapp         0/1     ImagePullBackOff   0          13m   10.10.6.73   node03.cbear.top   <none>           <none>
pod/demoapp-20792   1/1     Running            0          12m   10.10.7.87   node02.cbear.top   <none>           <none>

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service/kubernetes   ClusterIP   10.20.0.1    <none>        443/TCP   19h   <none>

使用类似如下命令列出kube-namespace名称空间中拥有k8s-app标签名称的所有Pod对象。

root@kubeadm-master1:~# kubectl get pods -l k8s-app -n kube-system
NAME                       READY   STATUS    RESTARTS   AGE
coredns-5f98f8d567-dszzv   1/1     Running   0          16h
coredns-5f98f8d567-pfwsd   1/1     Running   0          16h
kube-proxy-6wh65           1/1     Running   0          16h
kube-proxy-9gd47           1/1     Running   0          16h
kube-proxy-9l26z           1/1     Running   0          16h
kube-proxy-dntzj           1/1     Running   0          16h
kube-proxy-s465n           1/1     Running   0          16h
kube-proxy-tckql           1/1     Running   0          16h
#查看pod标签
root@kubeadm-master1:~# kubectl get pods -n kube-system --show-labels

kubectl get命令支持多种不同的输出格式 , 例如 wide、yaml、json、custom-columns、jsonpath和go-template等 , 每一种格式都以不同的输出格式打印资源对象的信息。例如 , 下面的命令能够取出kube-system名称空间中带有k8s-app=kube-dns标签的Pod 对象的资源名称

root@kubeadm-master1:~# kubectl get pods -l k8s-app -n kube-system -o jsonpath="{.items[0].metadata.name}"
coredns-5f98f8d567-dszzv

3.3 打印资源对象的详细信息

每个资源对象都有用户期望的状态(Spec)和现有的实际状态 (Status)两种状态信息 , kubectl get -o {yaml|josn}可分别以 YAML或JSON格式打印资源对象的规范 , 而kubectl describe命令则能够打印出指定资源对象的详细描述信息。例如 , 查看kube-system名称空间中API Server相关Pod对象的资源配置清单(期望的状态)及当前的状态信息 , 并输出为YAML格式 :

root@kubeadm-master1:~# kubectl get pods kube-apiserver-kubeadm-master1.cbear.top -o yaml -n kube-system

而kubectl describe命令还能显示当前对象相关的其他资源对象 , 如Event或Controller等。例如 , 查看kube-system名称空间中拥有标签component=kube-apiserver的Pod对象的详细描述信息 , 可以使用下面的命令:

root@kubeadm-master1:~# kubectl describe pods -l component=kube-apiserver -n kube-system

这两个命令都支持以TYPE NAME或TYPE/NAME的格式指定具体的资源对象 , 例如kube-apiserver-kubeadm-master1.cbear.top或pods/kube-apiserver-kubeadm-master1.cbear.top , 以了解特定资源对象的详细属性信息及状态信息。

3.4 打印容器中的日志信息

通常一个应用容器中仅会运行一个进程(及其子进程) , 该进程作为1号进程接收并处理信号 , 同时负责将日志直接输出至容器终端中 , 因此容器日志信息的获取一般要通过容器控制台进行。kubectl logs命令可打印Pod对象内指定容器的日志信息 ,

命令格式为kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options]。

若 Pod对象内仅有一个容器 , 则-c选项及容器名可选。例如 , 下面的命令先取出kube-system名称空间中带有指定标签的一个Pod对象 , 而第二条命令则能够查看该Pod对象的日志。

root@kubeadm-master1:~#  DNS_POD=$(kubectl get pods -l  k8s-app=kube-dns -n kube-system -o jsonpath="{.items[0].metadata.name}") 
root@kubeadm-master1:~# kubectl logs $DNS_POD -n kube-system
.:53
[INFO] plugin/reload: Running configuration SHA512 = cafbc5e0dc5c8a060ae940a73f02e0fcac78d825a9201b712844ee2911e1099026aeb263f4498b995830b269e979e02d0326e20bb7a2943aec9f4041ef9cad24
CoreDNS-1.11.1
linux/amd64, go1.20.7, ae2bbc2
[ERROR] plugin/errors: 2 9040257192140182538.5010192363804864375. HINFO: read udp 10.10.7.84:59517->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 9040257192140182538.5010192363804864375. HINFO: read udp 10.10.7.84:54996->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 9040257192140182538.5010192363804864375. HINFO: read udp 10.10.7.84:42350->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 9040257192140182538.5010192363804864375. HINFO: read udp 10.10.7.84:58862->114.114.114.114:53: i/o timeout

为上面的命令添加-f选项 , 还能用于持续监控指定容器中的日志输出 , 其行为类似于使用了-f选项的tail命令。

3.5 在容器中执行命令

容器的隔离属性使得对其内部信息的获取变得不再直观 , 这在用户需要了解容器内进程的运行特性、文件系统上的文件及路径布局等信息时需要穿透其隔离边界进行。kubectl exec命令便是在指定的容器运行其他应用程序的命令 , 例如在kube-system名称空间中的Pod对象kube-apiserver-master.ilinux.io上的唯一容器中运行ps命令:

root@kubeadm-master1:~# kubectl exec kube-apiserver-kubeadm-master1.cbear.top -n kube-system -- ps

root@kubeadm-master1:~# kubectl exec demoapp-7c58cd6bb-nxrtq  -n dev -- ps
PID   USER     TIME  COMMAND
    1 root      0:01 python3 /usr/local/bin/demo.py
    8 root      0:00 ps

类似于logs命令 , 若Pod对象中存在多个容器 , 需要以-c选项指定容器后才能运行指定的命令 , 而指定的命令程序也必须在容器中存在才能成功运行。

3.6 删除资源对象

kubectl delete命令能够删除指定的资源对象 , 例如下面的命令可删除default名称空间中名为demoapp-svc的Service资源对象:

root@kubeadm-master1:~# kubectl delete services demoapp-svc

而下面的命令可删除kube-system名称空间中带有k8s-app=kube proxy标签的所有Pod对象(危险操作 , 切勿在生产集群中测试执行):

root@kubeadm-master1:~# kubectl delete pods -l k8s-app=kube-proxy -n kube-system
pod "kube-proxy-6wh65" deleted
pod "kube-proxy-9gd47" deleted
pod "kube-proxy-9l26z" deleted
pod "kube-proxy-dntzj" deleted
pod "kube-proxy-s465n" deleted
pod "kube-proxy-tckql" deleted

若要删除指定名称空间中的所有某类对象 , 可以使用类似kubectl delete TYPE --all -n NS格式的命令。例如 , 下面的命令可删除 kube-public名称空间中的所有Pod对象 :

root@kubeadm-master1:~# kubectl delete pods --all -n kube-public

另外 , 有些资源类型支持优雅删除的机制 , 它们有着默认的删除宽限期 , 例如Pod资源的默认宽限期为30秒 , 但用户可在命令中使用-- grace-period选项或--now选项来覆盖默认的宽限期。下面的命令就用于强制删除指定的Pod对象 , 但这种删除操作可能会导致相关容器无法终止并退出。

root@kubeadm-master1:~# kubectl delete pods demoapp --force --grace-period=0
Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "demoapp" force deleted

需要特别说明的是 , 对于受控于控制器的对象来说 , 仅删除受控对象自身 , 其控制器可能会重建出类似的对象 , 例如Deployment控制器下的Pod对象被删除时即会被重建。

4. kubectl插件

kubectl插件是指能够由kubectl调用的外部独立应用程序 , 这类应用程序都以kubectl-$plugin_name格式命名 , 表现为kubectl的名字是$plugin_name的子命令。例如 , 应用程序/usr/bin/kubectl-whoami就是whoami插件 , 我们可以使用kubectl whoami的格式来运行它。因此 , 可为kubectl插件添加新的可用子命令 , 丰富kubectl的功能。

插件程序能够从kubectl继承环境信息 , 但kubectl的插件机制并不会在该程序及调用的外部程序之间传递任何信息 , 它仅仅提供了调用外部程序的一个统一接口 , 于是我们可以使用任何熟悉的脚本语言或编程语言来开发kubectl插件 , 但最终的脚本或程序文件需要以 “kubectl-”为名称前缀。而安装插件的过程 , 也不过是将插件程序的可执行文件移动到系统的PATH环境变量上 , 指向任一路径即可。事实上 , kubectl plugin list命令可遍历PATH环境变量指向的每一个路径 , 搜索并列出每一个以“kubectl-”为前缀的可执行程序文件路径。

Kubernetes SIG CLI社区还提供了一个插件管理器——Krew , 它能够帮助用户打包、分发、查找、安装和管理kubectl插件 , 项目地址为https://krew.sigs.k8s.io/。Krew以跨平台的方式打包和分发插件 , 因此单一打包格式即能适配主流的系统平台(Linux、Windows或 macOS等）。为了便于插件分发 , Krew还维护有一个插件索引 , 以方便用户发现主流的可用插件。 Krew自身也表现为kubectl的一个插件 , 需要以手动方式独立安装。下面的脚本(krew-install.sh)能自动完成Krew插件的安装 , 该脚本仅适用于类UNIX系统平台 , 并以bash解释器运行 , 其他平台上的部署方式请参考Krew项目的官方文档。

#!/bin/bash 
set -x; cd "$(mktemp -d)" 
curl -fSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.{tar.gz,yaml}"  
tar zxvf krew.tar.gz  
KREW=./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" 
"$KREW" install --manifest=krew.yaml --archive=krew.tar.gz 
"$KREW" update

Krew默认以用户主目录下的隐藏目录.krew为工作目录 , 由Krew安装的插件都位于$HOME/.krew/bin路径下 , 因此脚本执行完成后 , 会通过如下信息提示用户将该路径添加到PATH环境变量 , 并重启shell进程

WARNING: To be able to run kubectl plugins, you need to add the following to your ~/.bash_profile or ~/.bashrc: 
    export PATH="${PATH}:${HOME}/.krew/bin" 
and restart your shell

于是 , 我们编辑$HOME/.bash_profile文件 , 将export一行命令添加其中 , 并重启当前shell解释器。

~$ echo 'export PATH="${PATH}:${HOME}/.krew/bin"' >> $HOME/.bash_profile 
~$ exec $SHELL

设定完成后 , kubectl krew子命令便能执行Krew插件管理器的相关功能 , 例如查找和安装所需要的插件 , 它拥有help、list、 search、info、install、upgrade和uninstall等二级子命令。下面的命令搜索Krew索引中包含字符串who的插件。

~$ kubectl krew search who 
NAME     DESCRIPTION                                            INSTALLED 
who-can  Shows who has RBAC permissions to access Kubern...     no 
whoami   Show the subject that's currently authenticated...     no

插件的简要描述能够通过info子命令打印。例如 , 下面的命令打印了whoami插件的相关描述 , 该插件能够返回当前kubectl客户端将以哪个主体(subject)身份请求认证的信息。

~$ kubectl krew info whoami 
NAME: whoami 
…… 
DESCRIPTION:  
 This plugin show the subject that's currently authenticated as. 
……

安装插件则需要使用install命令 , 命令格式为install PLUGIN_NAME。仍然以whoami插件为例 , 使用如下命令即能完成该插件的安装。

~$ kubectl krew install whoami

whoami插件功能非常简单 , 它没有更多的选项可以使用 , 因此 , kubectl whoami便能返回当前kubectl客户端会以哪种身份凭据认证到 API Server。下面命令的结果显示 : 当前客户端基于kubeconfig配置文件(kubecfg)加载X509数字证书格式的身份凭据( certauth ) , 并由API Server认证为管理员(admin)。

~$ kubectl whoami 
kubecfg:certauth:admin

Krew索引中的各插件几乎都从更便捷、更丰富或更完整等角度进一步完善了kubectl功能。例如status能够以更加简便、直观的方式返回资源的简要状态 , ctx以更便捷的方式完成kubeconfig中的context 切换等。本书后面的章节也会用到其中的部分插件 , 包括whoami、 rbac-view、ns、ctx等 , 这里一并直接安装它们。

~$ kubectl krew install whoami rbac-view ns ctx

5. 命令式应用编排

本节使用示例镜像ikubernetes/demoapp:v1.0演示容器应用编排的基础操作 : 应用部署、访问、查看 , 服务暴露和应用扩缩容等。一般说来 , Kubernetes之上应用程序的基础管理操作由如下几个部分组成。

通过合用的控制器类的资源(例如Deployment或 ReplicationController)创建并管控Pod对象以运行特定的应用程序 : 无状态（stateless)应用的部署和控制通常使用Deployment控制器 , 而有状态应用则需要使用StatefulSet控制器或扩展的Operator。
为Pod对象创建Service对象 , 以便向客户端提供固定的访问端点 , 并能够借助KubeDNS进行服务发现。
随时按需获取各资源对象的简要或详细信息 , 以了解其运行状态。
如有需要 , 对支持扩缩容的应用按需进行扩容或缩容 ; 或者 , 为支持HPA的控制器组件(例如Deployment或 ReplicationController ) 创建HPA资源对象 , 以实现Pod副本数目的自动伸缩。
应用程序的镜像出现新版本时 , 对其执行更新操作 , 若相应的控制器支持 , 修改指定的控制器资源中Pod模板的容器镜像为指定的新版本即可自动触发更新过程。

本节中的操作示例仅演示的部分功能 , 即应用部署、访问、查看 , 以及服务暴露。

5.1 应用编排

在Kubernetes集群上自主运行的Pod对象在非计划内终止后 , 其生命周期也随之终结 , 用户需要再次手动创建类似的Pod对象才能确保其再次可用。对于Pod数量众多的场景 , 尤其是对微服务业务来说 , 用户必将疲于应付此类需求。自动化应用编排是Kubernetes的核心价值之一 , 将应用托管给控制器编排才是发挥Kubernetes作用的根本所在。

5.1.1 创建Deployment控制器对象

kubectl create deployment能够以“命令式命令”直接创建 Deployment控制器对象 , 经该对象编排的Pod对象将由该命令生成的 Pod模板自动创建 , 但需要用户以--image选项指定要使用的容器镜像。该命令的--dry-run={none|client|server}选项可用于测试运行 , 并不真正执行资源对象的创建过程 , 因而可用于在真正运行之前测试其是否能成功创建出指定的Deployment资源。例如 , 下面的命令会创建一个名为demoapp的Deployment控制器对象 , 它使用镜像 ikubernetes/demoapp:v1.0创建Pod对象 , 但仅用于测试 , 运行后即退出

root@kubeadm-master1:~#  kubectl create deployment demoapp --image="ikubernetes/demoapp:v1.0" --dry-run=client
deployment.apps/demoapp created (dry run)

确认测试命令无误后 , 可在移除--dry-run选项后再次执行命令以完成资源对象的创建。

root@kubeadm-master1:~#  kubectl create deployment demoapp --image="ikubernetes/demoapp:v1.0" 
deployment.apps/demoapp created

该命令创建的Deployment/demoapp对象会借助指定的镜像生成一个Pod , 并自动为其添加app=demoapp标签 , 而控制器对象自身也将使用该标签作为标签选择器。镜像ikubernetes/demoapp:v1.0中定义的容器主进程为默认监听于80端口的Web应用程序demoapp。 default名称空间中的 Deployment/demoapp对象基于默认的标签选择器编排根据指定的镜像文件创建的一个Pod对象。

资源对象创建完成后 , 通常需要了解其当前状态是否正常 , 以及是否符合用户期望的目标状态 , 相关的操作一般使用kubectl get、 kubectl describe等命令进行。

5.1.2 打印资源对象的相关信息

如前所述 , kubectl get命令可用于获取各种资源对象的相关信息 , 它能显示对象类型特有格式的简要信息 , 也能打印出YAML或JSON 格式的详细信息 , 还能使用Go模板自定义要显示的属性及信息等。例如 , 下面是查看前面创建的Deployment对象的相关运行状态的命令及其输出结果:

root@kubeadm-master1:~# kubectl get deployments/demoapp
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
demoapp   3/3     3            3           26m

get命令的默认输出格式是以指定的字段返回资源对象的简要信息 , 例如上面命令结果中的NAME和READY等 , 不同资源类型的输出结果也会有所区别。在上面显示Deployment资源简要信息的命令执行结果中 , 各字段基本可以做到见名知义

NAME : Deployment资源对象的名称。
READY : 以类似m/n格式返回两个数字 , m代表就绪的Pod数量 , n 表示期望的总的Pod数量。
UP-TO-DATE : 更新到最新版本定义的Pod对象副本数量 , 在控制器的滚动更新模式下 , 它表示已经完成版本更新的Pod对象副本数量。
AVAILABLE : 当前处于可用状态的Pod对象副本数量 , 即可正常提供服务的副本数。
AGE : 该资源的存在时长。

提示 : Deployment资源对象是通过ReplicaSet控制器对象作为中间层实例完成对Pod对象的控制 , 各Pod的名称也是由ReplicaSet 对象名称后跟几个随机字符构成。

Deployment/demoapp创建的唯一Pod对象运行正常与否、该对象被调度至哪个节点运行 , 以及当前是否就绪等也是用户在创建完成后应该关注的重点信息。由控制器创建的Pod对象的名称通常是以其隶属的 ReplicaSet对象的名称为前缀 , 以随机字符为后缀 , 例如下面命令以 app=demoapp为标签选择器打印筛选出的Pod对象的相关信息。

root@kubeadm-master1:~# kubectl get pods -l app=demoapp -o wide 
NAME                      READY   STATUS    RESTARTS   AGE   IP           NODE               NOMINATED NODE   READINESS GATES
demoapp-7c58cd6bb-bsh62   1/1     Running   0          29m   10.10.6.75   node03.cbear.top   <none>           <none>
demoapp-7c58cd6bb-kngv8   1/1     Running   0          31m   10.10.7.88   node02.cbear.top   <none>           <none>
demoapp-7c58cd6bb-x6x54   1/1     Running   0          43m   10.10.8.30   node01.cbear.top   <none>           <none>

在上面命令的执行结果中 , 每个字段代表Pod资源对象一个方面的属性 , 下面仅说明几个主要字段的功用。

READY: m/n格式 , m表示Pod中就绪状态的容器数量 , n表示Pod中总的容器数量。
STATUS: Pod的当前状态 , 其值可能是Pending、Running、 Succeeded、Failed和Unknown等其中之一 , 并存在某些类型的中间状态(容器状态)。
RESTARTS: Pod对象可能会因容器进程崩溃、超出资源限额等故障而被重启 , 此字段记录了它重启的次数。
IP: Pod的IP地址 , 通常由网络插件自动分配。
NODE : 该Pod对象绑定的Node , 目标Node由Scheduler负责挑选。确认Pod对象转为Running状态后 , 即可在集群中任一节点(或其他Pod对象)直接访问容器化应用的服务 , 如图2-11中节点Node X上的客户端程序Client , 或集群上运行在Pod中的客户端程序。

接下来 , 我们可在集群中任意一个节点上使用curl命令对地址为 10.10.6.75的Pod对象demoapp-7c58cd6bb-bsh62r的80端口发起服务请求。例如 , 将下面的命令运行在master1节点上。

root@kubeadm-master1:~# POD_IP=$(kubectl get pods -l app=demoapp -o jsonpath={.items[0].status.podIP}) 
root@kubeadm-master1:~# echo POD_IP
POD_IP
root@kubeadm-master1:~# echo $POD_IP
10.10.6.75
root@kubeadm-master1:~# curl http://${POD_IP}/
iKubernetes demoapp v1.0 !! ClientIP: 10.10.0.0, ServerName: demoapp-7c58cd6bb-bsh62, ServerIP: 10.10.6.75!

5.2 部署Service对象

简单来说 , Service对象就是一组Pod的逻辑组合 , 它通过称为 ClusterIP的地址和服务端口接收客户端请求 , 并将这些请求代理至使用标签选择器来过滤一个符合条件的Pod对象。

kubectl create service命令可创建Service对象以将应用程序 “暴露”于网络中 , 它使用的标签选择器为app=SVC_NAME。例如 , 下面的命令使用app=demoapp为标签选择器创建了Service/demoapp资源对象。

root@kubeadm-master1:~# kubectl create service nodeport demoapp --tcp=80 
service/demoapp created

在上面的命令中 , nodeport是指Service对象的类型 , 它会在集群中各节点上随机选择一个节点端口(hostPort)为该Service对象接入集群外部的访问流量 , 集群内部流量则由Service资源通过ClusterIP直接接入。命令选项--tcp=[:]用于指定Servcie 端口及容器上要暴露的端口 , 省略容器端口时表示与Service端口相同。创建完成后 , default名称空间中的对象及其通信示意图如图2-12 所示

我们仍然可以在集群节点上或者通过任意一个Pod对象来模拟集群内部客户端对Service/demoapp的访问 , 为了便于测试 , Kubernetes为各Service对象自动生成DNS记录及相应的名称解析功能。下面 , 在同一集群中的Pod对象中通过客户端程序发起访问测试来模拟图2-11中源自Pod对象Client的访问请求。

首先 , 使用kubectl run命令创建一个自主式Pod对象并直接接入其交互式接口 , 如下面命令的-it组合选项即用于交互式打开并保持其 shell命令行接口

root@kubeadm-master1:~# kubectl run client-pod --image="ikubernetes/admin-toolbox:v1.0" --rm -it --command -- /bin/sh
If you don't see a command prompt, try pressing enter.
[root@client-pod /]#

接下来 , 在client-pod中测试Service对象的名称解析功能 , 如下面命令中的demoapp是指Service对象名称 , 而default是该Service所属的名称空间 , svc代表Service资源 , 而cbear.local是集群域名, 安装时配置文件中指定的集群域名, 默认为cluster.local。其中的svc.cbear.local通常可以省略 , 如果客户端与目标Service 对象在同一名称空间中 , 则名称空间也可省略。

root@client-pod /]# nslookup  -query=A
> demoapp.default.svc.cbear.local
Server:		10.20.0.10
Address:	10.20.0.10#53

Name:	demoapp.default.svc.cbear.local
Address: 10.20.247.193
>

随后 , 可在client-pod通过crul命令对此前创建的Service对象的名称发起访问请求 , 下面的命令使用了短格式的服务名称。

[root@client-pod /]# curl http://demoapp.default
iKubernetes demoapp v1.0 !! ClientIP: 10.10.8.31, ServerName: demoapp-7c58cd6bb-kngv8, ServerIP: 10.10.7.88!

类似于列出Deployment控制器及Pod资源对象的方式 , kubectl get services命令能够列出Service对象的相关信息 , 例如下面的命令显示了Service对象demoapp的简要状态信息。

root@kubeadm-master1:~# kubectl get service/demoapp
NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
demoapp   NodePort   10.20.247.193   <none>        80:30263/TCP   31m

其中 , PORT(s)字段中表明 , 集群中各工作节点会捕获发往本地的目标端口为30263的流量 , 并将其代理至当前Service对象的80端口 , 于是 , 集群外部的用户可以使用当前集群中任一节点的此端口来请求 Service对象上的服务。CLUSTER-IP字段为当前Service的IP地址 , 它是一个虚拟IP , 并没有配置在集群中任何主机的任何接口之上 , 但每个Node上的kube-proxy都会为CLUSTER-IP所在的网络创建用于转发的 iptables或ipvs规则。此时 , 用户可于集群外部任一浏览器请求 Kubernetes集群任意一个节点的相关端口来进行访问测试。

5.3 扩容与缩容

前面示例中创建的Deployment对象demoapp仅创建了一个Pod对象 , 其所能够承载的访问请求数量受限于这个Pod对象的服务能力。请求流量上升到接近或超出其承载上限之前 , 用户可以通过Kubernetes 的应用“扩容”(scaling up)机制来增加Pod副本数量 , 从而提升其服务容量。相应地 , “缩容”是指缩减Pod副本数量 , 只不过这通常缘于与扩容操作相反的原因。 kubectl scale命令就是专用于变动控制器应用规模的命令 , 它支持对Deployment、ReplicaSet、StatefulSet等类型资源对象的扩容和缩容操作。例如 , 如果要将Deployment/demoapp中的Pod副本数量扩展为3个 , 可以使用如下命令完成。

root@kubeadm-master1:~# kubectl scale deployment/demoapp --replicas=3 
deployment.apps/demoapp scaled

而后列出由demoapp创建的Pod副本 , 便可确认其扩展操作的完成状态。如下命令显示出其Pod副本数量已经扩增至3个。其中包括此前的demoapp-7c58cd6bb-kngv8

root@kubeadm-master1:~# kubectl get pod 
NAME                      READY   STATUS    RESTARTS   AGE
demoapp-20792             1/1     Running   0          3h19m
demoapp-7c58cd6bb-2pwnj   1/1     Running   0          63s
demoapp-7c58cd6bb-kngv8   1/1     Running   0          82m
demoapp-7c58cd6bb-vmzmq   1/1     Running   0          63s

Service对象内置的负载均衡机制可在其后端副本数量不止一个时自动进行流量分发 , 它还会自动监控关联到的Pod的健康状态 , 以确保仅将请求流量分发至可用的后端Pod对象。因此 , Deployment对象 demoapp规模扩展完成后 , default名称空间中的资源对象及其关联关系就变成了如图2-13所示的情形。

而后由kubectl describe deployment命令打印Deployment对象 demoapp的详细信息 , 了解其应用规模的变动及当前Pod副本的状态等相关信息。由命令结果可以看出 , 其Pod副本数量的各项指标都已经转换为新的目标数量 , 而其事件信息中也有相应事件显示其扩增操作已成功完成。

root@kubeadm-master1:~# kubectl describe  deployment/demoapp 
Name:                   demoapp
Namespace:              default
CreationTimestamp:      Wed, 08 May 2024 11:29:08 +0000
Labels:                 app=demoapp
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=demoapp
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=demoapp
  Containers:
   demoapp:
    Image:        ikubernetes/demoapp:v1.0
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   demoapp-7c58cd6bb (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  42m    deployment-controller  Scaled down replica set demoapp-7c58cd6bb to 1 from 3
  Normal  ScalingReplicaSet  5m17s  deployment-controller  Scaled up replica set demoapp-7c58cd6bb to 3 from 1

Service对象demoapp的标签选择器动态纳入的新Pod副本也将成为该Service对象可用的代理后端 , 所有流量会被调度至其后端的所有 Pod对象之上 , 如图2-12所示。每个能够接收流量的后端称为一个端点 , 它通常表现为相应主机或容器上可接收特定流量的访问入口(套接字), 如下面命令结果中的Endpoints字段所示。

root@kubeadm-master1:~# kubectl describe  services/demoapp
Name:                     demoapp
Namespace:                default
Labels:                   app=demoapp
Annotations:              <none>
Selector:                 app=demoapp
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.20.247.193
IPs:                      10.20.247.193
Port:                     80  80/TCP
TargetPort:               80/TCP
NodePort:                 80  30263/TCP
Endpoints:                10.10.6.76:80,10.10.7.88:80,10.10.8.32:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

我们可以通过任何客户端对Service/demoapp的服务发起访问请求进行测试 , 这次我们在集群外的主机上通过NodePort对该服务发起持续访问 , 以测试Service对象的流量调度机制是否能够正常工作。由命令的响应结果显示 , Service/demoapp已然将请求调度至3 个不同的后端Pod之上。

root@kubeadm-master2:~#  while true; do curl http://192.168.71.30:30263/; sleep 0.2; done
iKubernetes demoapp v1.0 !! ClientIP: 10.10.1.0, ServerName: demoapp-7c58cd6bb-2pwnj, ServerIP: 10.10.6.76!
iKubernetes demoapp v1.0 !! ClientIP: 10.10.1.0, ServerName: demoapp-7c58cd6bb-vmzmq, ServerIP: 10.10.8.32!
iKubernetes demoapp v1.0 !! ClientIP: 10.10.1.0, ServerName: demoapp-7c58cd6bb-kngv8, ServerIP: 10.10.7.88!

应用规模缩容的方式和扩容相似 , 只不过是将Pod副本的数量调至比原来小的数字。例如 , 将demoapp的Pod副本缩减至2个 , 可以使用类似如下命令进行。

root@kubeadm-master1:~#  kubectl scale deployment/demoapp --replicas=2 
deployment.apps/demoapp scaled

缩容完成后 , Service/demoapp的后端端点数量也会随之动态变动。至此 , 功能基本完整的容器化应用在Kubernetes上已经部署完成 , 即便是部署一个略复杂的分层应用 , 也只需要通过合适的镜像以类似的方式就能完成

5.4 修改与删除对象

成功创建于Kubernetes之上的资源对象也称为活动对象(live object) , 其配置规范(live object configuration)由API Server 保存在集群状态存储系统etcd中。kubectl edit命令可调用默认编辑器对活动对象的可配置属性进行编辑。例如 , 若需要将此前创建的 Service/demoapp对象的类型修改为ClusterIP , 可以使用kubectl edit service demoapp命令打开编辑界面后 , 通过将type属性的值修改为ClusterIP使其实时生效

提示 : 不同资源类型的资源规范相差很大 , 而且未必所有字段都支持运行时修改。

有些命令是kubectl edit命令某一部分功能的二次封装 , 例如 kubectl scale命令不过是专用于修改资源对象的replicas属性值而已 , 而kubectl set image通常用于修改工作负载型控制器资源规范中 Pod模板的容器镜像 , 这两个命令同样直接作用于活动对象。不再有价值的活动对象可使用kubectl delete命令予以删除。例如 , 下面的命令能够删除service/demoapp资源对象:

root@kubeadm-master1:~#  kubectl delete service/demoapp
service "demoapp" deleted

有时候需要清空某一类型下的所有对象 , 此时只需要将上面命令对象名称换成--all选项便能实现。例如 , 删除dafault名称空间中所有的Deployment控制器:

root@kubeadm-master1:~# kubectl delete deployment --all 
deployment.apps "demoapp" deleted

需要注意的是 , 受控于控制器的Pod对象在删除后会被重建 , 因而删除此类对象需要直接删除其控制器对象。默认情况下 , 删除 Deployment一类的工作负载型控制器资源会级联删除相关的所有Pod对象 , 若要禁用该功能 , 需要在删除命令中使用--cascade=false选项。

显然 , 直接命令式管理资源对象存在较大的局限性 , 它们在设置资源对象属性方面提供的配置能力相当有限 , 而且有不少资源并不支持通过命令操作进行创建。例如 , 用户无法创建带有多个容器的Pod对象 , 也无法为Pod对象创建存储卷。因此 , 资源对象的更有效管理方式是使用保存有对象配置信息的配置清单。