kubectl
- 1: kubectl 概述
- 2: JSONPath 支持
- 3: kubectl
- 4: kubectl 命令
- 5: kubectl 备忘单
- 6: kubectl 的用法约定
- 7: 适用于 Docker 用户的 kubectl
1 - kubectl 概述
你可以使用 Kubectl 命令行工具管理 Kubernetes 集群。
kubectl
在 $HOME/.kube
目录中查找一个名为 config
的配置文件。
你可以通过设置 KUBECONFIG 环境变量或设置
--kubeconfig
参数来指定其它 kubeconfig 文件。
本文概述了 kubectl
语法和命令操作描述,并提供了常见的示例。
有关每个命令的详细信息,包括所有受支持的参数和子命令,
请参阅 kubectl 参考文档。
有关安装说明,请参见安装 kubectl 。
语法
使用以下语法 kubectl
从终端窗口运行命令:
kubectl [command] [TYPE] [NAME] [flags]
其中 command
、TYPE
、NAME
和 flags
分别是:
command
:指定要对一个或多个资源执行的操作,例如create
、get
、describe
、delete
。TYPE
:指定资源类型。资源类型不区分大小写, 可以指定单数、复数或缩写形式。例如,以下命令输出相同的结果:kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1
NAME
:指定资源的名称。名称区分大小写。 如果省略名称,则显示所有资源的详细信息kubectl get pods
。在对多个资源执行操作时,你可以按类型和名称指定每个资源,或指定一个或多个文件:
要按类型和名称指定资源:
要对所有类型相同的资源进行分组,请执行以下操作:
TYPE1 name1 name2 name<#>
。例子:
kubectl get pod example-pod1 example-pod2
分别指定多个资源类型:
TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>
。例子:
kubectl get pod/example-pod1 replicationcontroller/example-rc1
用一个或多个文件指定资源:
-f file1 -f file2 -f file<#>
- 使用 YAML 而不是 JSON
因为 YAML 更容易使用,特别是用于配置文件时。
例子:
kubectl get -f ./pod.yaml
- 使用 YAML 而不是 JSON
因为 YAML 更容易使用,特别是用于配置文件时。
例子:
flags
: 指定可选的参数。例如,可以使用-s
或-server
参数指定 Kubernetes API 服务器的地址和端口。
注意:从命令行指定的参数会覆盖默认值和任何相应的环境变量。
如果你需要帮助,从终端窗口运行 kubectl help
。
操作
下表包含所有 kubectl 操作的简短描述和普通语法:
操作 | 语法 | 描述 |
---|---|---|
alpha | kubectl alpha SUBCOMMAND [flags] | 列出与 alpha 特性对应的可用命令,这些特性在 Kubernetes 集群中默认情况下是不启用的。 |
annotate | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 |
api-resources | kubectl api-resources [flags] | 列出可用的 API 资源。 |
api-versions | kubectl api-versions [flags] | 列出可用的 API 版本。 |
apply | kubectl apply -f FILENAME [flags] | 从文件或 stdin 对资源应用配置更改。 |
attach | kubectl attach POD -c CONTAINER [-i] [-t] [flags] | 附加到正在运行的容器,查看输出流或与容器(stdin)交互。 |
auth | kubectl auth [flags] [options] | 检查授权。 |
autoscale | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动伸缩由副本控制器管理的一组 pod。 |
certificate | kubectl certificate SUBCOMMAND [options] | 修改证书资源。 |
cluster-info | kubectl cluster-info [flags] | 显示有关集群中主服务器和服务的端口信息。 |
completion | kubectl completion SHELL [options] | 为指定的 shell (bash 或 zsh)输出 shell 补齐代码。 |
config | kubectl config SUBCOMMAND [flags] | 修改 kubeconfig 文件。有关详细信息,请参阅各个子命令。 |
convert | kubectl convert -f FILENAME [options] | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。 |
cordon | kubectl cordon NODE [options] | 将节点标记为不可调度。 |
cp | kubectl cp <file-spec-src> <file-spec-dest> [options] | 在容器之间复制文件和目录。 |
create | kubectl create -f FILENAME [flags] | 从文件或 stdin 创建一个或多个资源。 |
delete | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 从文件、标准输入或指定标签选择器、名称、资源选择器或资源中删除资源。 |
describe | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 |
diff | kubectl diff -f FILENAME [flags] | 将 live 配置和文件或标准输入做对比 (BETA) |
drain | kubectl drain NODE [options] | 腾空节点以准备维护。 |
edit | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 |
exec | kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]] | 对 pod 中的容器执行命令。 |
explain | kubectl explain [--recursive=false] [flags] | 获取多种资源的文档。例如 pod, node, service 等。 |
expose | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 将副本控制器、服务或 pod 作为新的 Kubernetes 服务暴露。 |
get | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 列出一个或多个资源。 |
kustomize | kubectl kustomize <dir> [flags] [options] | 列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径,或者是 git 存储库 URL,其路径后缀相对于存储库根目录指定了相同的路径。 |
label | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的标签。 |
logs | kubectl logs POD [-c CONTAINER] [--follow] [flags] | 在 pod 中打印容器的日志。 |
options | kubectl options | 全局命令行选项列表,适用于所有命令。 |
patch | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 使用策略合并 patch 程序更新资源的一个或多个字段。 |
plugin | kubectl plugin [flags] [options] | 提供用于与插件交互的实用程序。 |
port-forward | kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags] | 将一个或多个本地端口转发到一个 pod。 |
proxy | kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags] | 运行 Kubernetes API 服务器的代理。 |
replace | kubectl replace -f FILENAME | 从文件或标准输入中替换资源。 |
rollout | kubectl rollout SUBCOMMAND [options] | 管理资源的部署。有效的资源类型包括:Deployments, DaemonSets 和 StatefulSets。 |
run | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server | client | none] [--overrides=inline-json] [flags] | 在集群上运行指定的镜像。 |
scale | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 更新指定副本控制器的大小。 |
set | kubectl set SUBCOMMAND [options] | 配置应用程序资源。 |
taint | kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options] | 更新一个或多个节点上的污点。 |
top | kubectl top [flags] [options] | 显示资源(CPU/内存/存储)的使用情况。 |
uncordon | kubectl uncordon NODE [options] | 将节点标记为可调度。 |
version | kubectl version [--client] [flags] | 显示运行在客户端和服务器上的 Kubernetes 版本。 |
wait | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 实验性:等待一种或多种资源的特定条件。 |
了解更多有关命令操作的信息,请参阅 kubectl 参考文档。
资源类型
下表列出所有受支持的资源类型及其缩写别名:
(以下输出可以通过 kubectl api-resources
获取,内容以 Kubernetes 1.19.1 版本为准。)
资源名 | 缩写名 | API 分组 | 按命名空间 | 资源类型 |
---|---|---|---|---|
bindings | true | Binding | ||
componentstatuses | cs | false | ComponentStatus | |
configmaps | cm | true | ConfigMap | |
endpoints | ep | true | Endpoints | |
events | ev | true | Event | |
limitranges | limits | true | LimitRange | |
namespaces | ns | false | Namespace | |
nodes | no | false | Node | |
persistentvolumeclaims | pvc | true | PersistentVolumeClaim | |
persistentvolumes | pv | false | PersistentVolume | |
pods | po | true | Pod | |
podtemplates | true | PodTemplate | ||
replicationcontrollers | rc | true | ReplicationController | |
resourcequotas | quota | true | ResourceQuota | |
secrets | true | Secret | ||
serviceaccounts | sa | true | ServiceAccount | |
services | svc | true | Service | |
mutatingwebhookconfigurations | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | |
validatingwebhookconfigurations | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | |
customresourcedefinitions | crd,crds | apiextensions.k8s.io | false | CustomResourceDefinition |
apiservices | apiregistration.k8s.io | false | APIService | |
controllerrevisions | apps | true | ControllerRevision | |
daemonsets | ds | apps | true | DaemonSet |
deployments | deploy | apps | true | Deployment |
replicasets | rs | apps | true | ReplicaSet |
statefulsets | sts | apps | true | StatefulSet |
tokenreviews | authentication.k8s.io | false | TokenReview | |
localsubjectaccessreviews | authorization.k8s.io | true | LocalSubjectAccessReview | |
selfsubjectaccessreviews | authorization.k8s.io | false | SelfSubjectAccessReview | |
selfsubjectrulesreviews | authorization.k8s.io | false | SelfSubjectRulesReview | |
subjectaccessreviews | authorization.k8s.io | false | SubjectAccessReview | |
horizontalpodautoscalers | hpa | autoscaling | true | HorizontalPodAutoscaler |
cronjobs | cj | batch | true | CronJob |
jobs | batch | true | Job | |
certificatesigningrequests | csr | certificates.k8s.io | false | CertificateSigningRequest |
leases | coordination.k8s.io | true | Lease | |
endpointslices | discovery.k8s.io | true | EndpointSlice | |
events | ev | events.k8s.io | true | Event |
ingresses | ing | extensions | true | Ingress |
flowschemas | flowcontrol.apiserver.k8s.io | false | FlowSchema | |
prioritylevelconfigurations | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | |
ingressclasses | networking.k8s.io | false | IngressClass | |
ingresses | ing | networking.k8s.io | true | Ingress |
networkpolicies | netpol | networking.k8s.io | true | NetworkPolicy |
runtimeclasses | node.k8s.io | false | RuntimeClass | |
poddisruptionbudgets | pdb | policy | true | PodDisruptionBudget |
podsecuritypolicies | psp | policy | false | PodSecurityPolicy |
clusterrolebindings | rbac.authorization.k8s.io | false | ClusterRoleBinding | |
clusterroles | rbac.authorization.k8s.io | false | ClusterRole | |
rolebindings | rbac.authorization.k8s.io | true | RoleBinding | |
roles | rbac.authorization.k8s.io | true | Role | |
priorityclasses | pc | scheduling.k8s.io | false | PriorityClass |
csidrivers | storage.k8s.io | false | CSIDriver | |
csinodes | storage.k8s.io | false | CSINode | |
storageclasses | sc | storage.k8s.io | false | StorageClass |
volumeattachments | storage.k8s.io | false | VolumeAttachment |
输出选项
有关如何格式化或排序某些命令的输出的信息,请使用以下部分。有关哪些命令支持各种输出选项的详细信息,请参阅kubectl 参考文档。
格式化输出
所有 kubectl
命令的默认输出格式都是人类可读的纯文本格式。要以特定格式向终端窗口输出详细信息,可以将 -o
或 --output
参数添加到受支持的 kubectl
命令中。
语法
kubectl [command] [TYPE] [NAME] -o=<output_format>
根据 kubectl
操作,支持以下输出格式:
Output format | Description |
---|---|
-o custom-columns=<spec> | 使用逗号分隔的自定义列列表打印表。 |
-o custom-columns-file=<filename> | 使用 <filename> 文件中的自定义列模板打印表。 |
-o json | 输出 JSON 格式的 API 对象 |
-o jsonpath=<template> | 打印 jsonpath 表达式定义的字段 |
-o jsonpath-file=<filename> | 打印 <filename> 文件中 jsonpath 表达式定义的字段。 |
-o name | 仅打印资源名称而不打印任何其他内容。 |
-o wide | 以纯文本格式输出,包含任何附加信息。对于 pod 包含节点名。 |
-o yaml | 输出 YAML 格式的 API 对象。 |
示例
在此示例中,以下命令将单个 pod 的详细信息输出为 YAML 格式的对象:
kubectl get pod web-pod-13je7 -o yaml
请记住:有关每个命令支持哪种输出格式的详细信息,请参阅 kubectl 参考文档。
自定义列
要定义自定义列并仅将所需的详细信息输出到表中,可以使用该 custom-columns 选项。你可以选择内联定义自定义列或使用模板文件:-o=custom-columns=<spec>
或 -o=custom-columns-file=<filename>
。
示例
内联:
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
模板文件:
kubectl get pods <pod-name> -o custom-columns-file=template.txt
其中,template.txt
文件包含:
NAME RSRC
metadata.name metadata.resourceVersion
运行任何一个命令的结果类似于:
NAME RSRC
submit-queue 610995
Server-side 列
kubectl
支持从服务器接收关于对象的特定列信息。
这意味着对于任何给定的资源,服务器将返回与该资源相关的列和行,以便客户端打印。
通过让服务器封装打印的细节,这允许在针对同一集群使用的客户端之间提供一致的人类可读输出。
此功能默认启用。要禁用它,请将该 --server-print=false
参数添加到 kubectl get
命令中。
例子:
要打印有关 pod 状态的信息,请使用如下命令:
kubectl get pods <pod-name> --server-print=false
输出类似于:
NAME AGE
pod-name 1m
排序列表对象
要将对象排序后输出到终端窗口,可以将 --sort-by
参数添加到支持的 kubectl
命令。通过使用 --sort-by
参数指定任何数字或字符串字段来对对象进行排序。要指定字段,请使用 jsonpath 表达式。
语法
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
示例
要打印按名称排序的 pod 列表,请运行:
kubectl get pods --sort-by=.metadata.name
示例:常用操作
使用以下示例集来帮助你熟悉运行常用 kubectl 操作:
kubectl apply
- 以文件或标准输入为准应用或更新资源。
# 使用 example-service.yaml 中的定义创建服务。
kubectl apply -f example-service.yaml
# 使用 example-controller.yaml 中的定义创建 replication controller。
kubectl apply -f example-controller.yaml
# 使用 <directory> 路径下的任意 .yaml, .yml, 或 .json 文件 创建对象。
kubectl apply -f <directory>
kubectl get
- 列出一个或多个资源。
# 以纯文本输出格式列出所有 pod。
kubectl get pods
# 以纯文本输出格式列出所有 pod,并包含附加信息(如节点名)。
kubectl get pods -o wide
# 以纯文本输出格式列出具有指定名称的副本控制器。提示:你可以使用别名 'rc' 缩短和替换 'replicationcontroller' 资源类型。
kubectl get replicationcontroller <rc-name>
# 以纯文本输出格式列出所有副本控制器和服务。
kubectl get rc,services
# 以纯文本输出格式列出所有守护程序集,包括未初始化的守护程序集。
kubectl get ds --include-uninitialized
# 列出在节点 server01 上运行的所有 pod
kubectl get pods --field-selector=spec.nodeName=server01
kubectl describe
- 显示一个或多个资源的详细状态,默认情况下包括未初始化的资源。
# 显示名称为 <node-name> 的节点的详细信息。
kubectl describe nodes <node-name>
# 显示名为 <pod-name> 的 pod 的详细信息。
kubectl describe pods/<pod-name>
# 显示由名为 <rc-name> 的副本控制器管理的所有 pod 的详细信息。
# 记住:副本控制器创建的任何 pod 都以复制控制器的名称为前缀。
kubectl describe pods <rc-name>
# 描述所有的 pod,不包括未初始化的 pod
kubectl describe pods
说明:
kubectl get
命令通常用于检索同一资源类型的一个或多个资源。 它具有丰富的参数,允许你使用-o
或--output
参数自定义输出格式。你可以指定-w
或--watch
参数以开始观察特定对象的更新。kubectl describe
命令更侧重于描述指定资源的许多相关方面。它可以调用对API 服务器
的多个 API 调用来为用户构建视图。 例如,该kubectl describe node
命令不仅检索有关节点的信息,还检索在其上运行的 pod 的摘要,为节点生成的事件等。
kubectl delete
- 从文件、stdin 或指定标签选择器、名称、资源选择器或资源中删除资源。
# 使用 pod.yaml 文件中指定的类型和名称删除 pod。
kubectl delete -f pod.yaml
# 删除所有带有 '<label-key>=<label-value>' 标签的 Pod 和服务。
kubectl delete pods,services -l <label-key>=<label-value>
# 删除所有 pod,包括未初始化的 pod。
kubectl delete pods --all
kubectl exec
- 对 pod 中的容器执行命令。
# 从 pod <pod-name> 中获取运行 'date' 的输出。默认情况下,输出来自第一个容器。
kubectl exec <pod-name> -- date
# 运行输出 'date' 获取在容器的 <container-name> 中 pod <pod-name> 的输出。
kubectl exec <pod-name> -c <container-name> -- date
# 获取一个交互 TTY 并运行 /bin/bash <pod-name >。默认情况下,输出来自第一个容器。
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs
- 打印 Pod 中容器的日志。
# 从 pod 返回日志快照。
kubectl logs <pod-name>
# 从 pod <pod-name> 开始流式传输日志。这类似于 'tail -f' Linux 命令。
kubectl logs -f <pod-name>
示例:创建和使用插件
使用以下示例来帮助你熟悉编写和使用 kubectl
插件:
# 用任何语言创建一个简单的插件,并为生成的可执行文件命名
# 以前缀 "kubectl-" 开始
cat ./kubectl-hello
#!/bin/sh
# 这个插件打印单词 "hello world"
echo "hello world"
这个插件写好了,把它变成可执行的:
sudo chmod a+x ./kubectl-hello
# 并将其移动到路径中的某个位置
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 你现在已经创建并"安装了"一个 kubectl 插件。
# 你可以开始使用这个插件,从 kubectl 调用它,就像它是一个常规命令一样
kubectl hello
hello world
# 你可以"卸载"一个插件,只需从你的路径中删除它
sudo rm /usr/local/bin/kubectl-hello
为了查看可用的所有 kubectl
插件,你可以使用 kubectl plugin list
子命令:
kubectl plugin list
输出类似于:
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list
指令也可以向你告警哪些插件被运行,或是被其它插件覆盖了,例如:
sudo chmod -x /usr/local/bin/kubectl-foo # 删除执行权限
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
你可以将插件视为在现有 kubectl 命令之上构建更复杂功能的一种方法:
cat ./kubectl-whoami
接下来的几个示例假设你已经将 kubectl-whoami
设置为以下内容:
#!/bin/bash
#这个插件利用 `kubectl config` 命令基于当前所选上下文输出当前用户的信息
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
运行以上命令将为你提供一个输出,其中包含 KUBECONFIG 文件中当前上下文的用户:
#!/bin/bash
# 使文件成为可执行的
sudo chmod +x ./kubectl-whoami
# 然后移动到你的路径中
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
要了解关于插件的更多信息,请查看示例 cli 插件。
接下来
2 - JSONPath 支持
Kubectl 支持 JSONPath 模板。
JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。Kubectl 使用 JSONPath 表达式来过滤 JSON 对象中的特定字段并格式化输出。除了原始的 JSONPath 模板语法,以下函数和语法也是有效的:
- 使用双引号将 JSONPath 表达式内的文本引起来。
- 使用
range
,end
运算符来迭代列表。 - 使用负片索引后退列表。负索引不会“环绕”列表,并且只要
-index + listLength> = 0
就有效。
说明:
$
运算符是可选的,因为默认情况下表达式总是从根对象开始。结果对象将作为其 String() 函数输出。
给定 JSON 输入:
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
函数 | 描述 | 示例 | 结果 |
---|---|---|---|
text | 纯文本 | kind is {.kind} | kind is List |
@ | 当前对象 | {@} | 与输入相同 |
. or [] | 子运算符 | {.kind} , {['kind']} or {['name\.type']} | List |
.. | 递归下降 | {..name} | 127.0.0.1 127.0.0.2 myself e2e |
* | 通配符。获取所有对象 | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2] |
[start:end :step] | 下标运算符 | {.users[0].name} | myself |
[,] | 并集运算符 | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] |
?() | 过滤 | {.users[?(@.name=="e2e")].user.password} | secret |
range , end | 迭代列表 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] |
'' | 引用解释执行字符串 | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2 |
使用 kubectl
和 JSONPath 表达式的示例:
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
说明:在 Windows 上,对于任何包含空格的 JSONPath 模板,您必须使用双引号(不是上面 bash 所示的单引号)。 反过来,这意味着您必须在模板中的所有文字周围使用单引号或转义的双引号。 例如:
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
说明:不支持 JSONPath 正则表达式。如需使用正则表达式进行匹配操作,您可以使用如
jq
之类的工具。# kubectl 的 JSONpath 输出不支持正则表达式 # 下面的命令不会生效 kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' # 下面的命令可以获得所需的结果 kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
3 - kubectl
简介
kubectl 管理控制 Kubernetes 集群。
获取更多信息,请访问 kubectl 概述。
kubectl [flags]
选项
--add-dir-header | |
设置为 true 表示添加文件目录到日志信息头中 | |
--alsologtostderr | |
表示将日志输出到文件的同时输出到 stderr | |
--as string | |
以指定用户的身份执行操作 | |
--as-group stringArray | |
模拟指定的组来执行操作,可以使用这个标志来指定多个组。 | |
--azure-container-registry-config string | |
包含 Azure 容器仓库配置信息的文件的路径。 | |
--cache-dir string 默认值: "$HOME/.kube/cache" | |
默认缓存目录 | |
--certificate-authority string | |
指向证书机构的 cert 文件路径 | |
--client-certificate string | |
TLS 使用的客户端证书路径 | |
--client-key string | |
TLS 使用的客户端密钥文件路径 | |
--cloud-provider-gce-l7lb-src-cidrs cidrs 默认值: 130.211.0.0/22,35.191.0.0/16 | |
在 GCE 防火墙中开放的 CIDR,用来进行 L7 LB 流量代理和健康检查。 | |
--cloud-provider-gce-lb-src-cidrs cidrs 默认值: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16 | |
在 GCE 防火墙中开放的 CIDR,用来进行 L4 LB 流量代理和健康检查。 | |
--cluster string | |
要使用的 kubeconfig 集群的名称 | |
--context string | |
要使用的 kubeconfig 上下文的名称 | |
--default-not-ready-toleration-seconds int 默认值: 300 | |
表示 `notReady` 状态的容忍度秒数:默认情况下,`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。 | |
--default-unreachable-toleration-seconds int 默认值: 300 | |
表示 `unreachable` 状态的容忍度秒数:默认情况下,`NoExecute` 被添加到尚未具有此容忍度的每个 Pod 中。 | |
-h, --help | |
kubectl 操作的帮助命令 | |
--insecure-skip-tls-verify | |
设置为 true,则表示不会检查服务器证书的有效性。这样会导致您的 HTTPS 连接不安全。 | |
--kubeconfig string | |
CLI 请求使用的 kubeconfig 配置文件的路径。 | |
--log-backtrace-at traceLocation 默认值: 0 | |
当日志机制运行到指定文件的指定行(file:N)时,打印调用堆栈信息 | |
--log-dir string | |
如果不为空,则将日志文件写入此目录 | |
--log-file string | |
如果不为空,则将使用此日志文件 | |
--log-file-max-size uint 默认值: 1800 | |
定义日志文件的最大尺寸。单位为兆字节。如果值设置为 0,则表示日志文件大小不受限制。 | |
--log-flush-frequency duration 默认值: 5s | |
两次日志刷新操作之间的最长时间(秒) | |
--logtostderr 默认值: true | |
日志输出到 stderr 而不是文件中 | |
--match-server-version | |
要求客户端版本和服务端版本相匹配 | |
-n, --namespace string | |
如果存在,CLI 请求将使用此命名空间 | |
--one-output | |
如果为 true,则只将日志写入初始严重级别(而不是同时写入所有较低的严重级别)。 | |
--password string | |
API 服务器进行基本身份验证的密码 | |
--profile string 默认值: "none" | |
要记录的性能指标的名称。可取 (none|cpu|heap|goroutine|threadcreate|block|mutex) 其中之一。 | |
--profile-output string 默认值: "profile.pprof" | |
用于转储所记录的性能信息的文件名 | |
--request-timeout string 默认值: "0" | |
放弃单个服务器请求之前的等待时间,非零值需要包含相应时间单位(例如:1s、2m、3h)。零值则表示不做超时要求。 | |
-s, --server string | |
Kubernetes API 服务器的地址和端口 | |
--skip-headers | |
设置为 true 则表示跳过在日志消息中出现 header 前缀信息 | |
--skip-log-headers | |
设置为 true 则表示在打开日志文件时跳过 header 信息 | |
--stderrthreshold severity 默认值: 2 | |
等于或高于此阈值的日志将输出到标准错误输出(stderr) | |
--token string | |
用于对 API 服务器进行身份认证的持有者令牌 | |
--user string | |
指定使用 kubeconfig 配置文件中的用户名 | |
--username string | |
用于 API 服务器的基本身份验证的用户名 | |
-v, --v Level | |
指定输出日志的日志详细级别 | |
--version version[=true] | |
打印 kubectl 版本信息并退出 | |
--vmodule moduleSpec | |
以逗号分隔的 pattern=N 设置列表,用于过滤文件的日志记录 |
另请参见
- kubectl annotate - 更新资源所关联的注解
- kubectl api-resources - 打印服务器上所支持的 API 资源
- kubectl api-versions - 以“组/版本”的格式输出服务端所支持的 API 版本
- kubectl apply - 基于文件名或标准输入,将新的配置应用到资源上
- kubectl attach - 连接到一个正在运行的容器
- kubectl auth - 检查授权信息
- kubectl autoscale - 对一个资源对象(Deployment、ReplicaSet 或 ReplicationController )进行扩缩
- kubectl certificate - 修改证书资源
- kubectl cluster-info - 显示集群信息
- kubectl completion - 根据已经给出的 Shell(bash 或 zsh),输出 Shell 补全后的代码
- kubectl config - 修改 kubeconfig 配置文件
- kubectl convert - 在不同的 API 版本之间转换配置文件
- kubectl cordon - 标记节点为不可调度的
- kubectl cp - 将文件和目录拷入/拷出容器
- kubectl create - 通过文件或标准输入来创建资源
- kubectl debug - 创建用于排查工作负载和节点故障的调试会话
- kubectl delete - 通过文件名、标准输入、资源和名字删除资源,或者通过资源和标签选择器来删除资源
- kubectl describe - 显示某个资源或某组资源的详细信息
- kubectl diff - 显示目前版本与将要应用的版本之间的差异
- kubectl drain - 腾空节点,准备维护
- kubectl edit - 修改服务器上的某资源
- kubectl exec - 在容器中执行相关命令
- kubectl explain - 显示资源文档说明
- kubectl expose - 给定副本控制器、服务、Deployment 或 Pod,将其暴露为新的 kubernetes Service
- kubectl get - 显示一个或者多个资源信息
- kubectl kustomize - 从目录或远程 URL 中构建 kustomization
- kubectl label - 更新资源的标签
- kubectl logs - 输出 pod 中某容器的日志
- kubectl options - 打印所有命令都支持的共有参数列表
- kubectl patch - 基于策略性合并修补(Stategic Merge Patch)规则更新某资源中的字段
- kubectl plugin - 运行命令行插件
- kubectl port-forward - 将一个或者多个本地端口转发到 pod
- kubectl proxy - 运行一个 kubernetes API 服务器代理
- kubectl replace - 基于文件名或标准输入替换资源
- kubectl rollout - 管理资源的上线
- kubectl run - 在集群中使用指定镜像启动容器
- kubectl scale - 为一个 Deployment、ReplicaSet 或 ReplicationController 设置一个新的规模尺寸值
- kubectl set - 为对象设置功能特性
- kubectl taint - 在一个或者多个节点上更新污点配置
- kubectl top - 显示资源(CPU /内存/存储)使用率
- kubectl uncordon - 标记节点为可调度的
- kubectl version - 打印客户端和服务器的版本信息
- kubectl wait - 实验性:等待一个或多个资源达到某种状态
4 - kubectl 命令
5 - kubectl 备忘单
本页列举了常用的 “kubectl” 命令和标志
Kubectl 自动补全
BASH
source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全,要先安装 bash-completion 包。
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全
您还可以为 kubectl
使用一个速记别名,该别名也可以与 completion 一起使用:
alias k=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全
Kubectl 上下文和配置
设置 kubectl
与哪个 Kubernetes 集群进行通信并修改配置信息。
查看使用 kubeconfig 跨集群授权访问
文档获取配置文件详细信息。
kubectl config view # 显示合并的 kubeconfig 配置。
# 同时使用多个 kubeconfig 文件并查看合并的配置
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
# 获取 e2e 用户的密码
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户
kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表
kubectl config get-contexts # 显示上下文列表
kubectl config current-context # 展示当前所处的上下文
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
# 添加新的用户配置到 kubeconf 中,使用 basic auth 进行身份认证
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# 在指定上下文中持久性地保存名字空间,供所有后续 kubectl 命令使用
kubectl config set-context --current --namespace=ggckad-s2
# 使用特定的用户名和名字空间设置上下文
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # 删除用户 foo
Kubectl apply
apply
通过定义 Kubernetes 资源的文件来管理应用。
它通过运行 kubectl apply
在集群中创建和更新资源。
这是在生产中管理 Kubernetes 应用的推荐方法。
参见 Kubectl 文档。
创建对象
Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名有
.yaml
、.yml
和 .json
。
kubectl apply -f ./my-manifest.yaml # 创建资源
kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建
kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源
kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源
kubectl create deployment nginx --image=nginx # 启动单实例 nginx
# 创建一个打印 “Hello World” 的 Job
kubectl create job hello --image=busybox -- echo "Hello World"
# 创建一个打印 “Hello World” 间隔1分钟的 CronJob
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"
kubectl explain pods # 获取 pod 清单的文档说明
# 从标准输入创建多个 YAML 对象
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF
# 创建有多个 key 的 Secret
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
查看和查找资源
# get 命令的基本输出
kubectl get services # 列出当前命名空间下的所有 services
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods
kubectl get pods -o wide # 列出当前命名空间下的全部 Pods,并显示更详细的信息
kubectl get deployment my-dep # 列出某个特定的 Deployment
kubectl get pods # 列出当前命名空间下的全部 Pods
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
# describe 命令的详细输出
kubectl describe nodes my-node
kubectl describe pods my-pod
# 列出当前名字空间下所有 Services,按名称排序
kubectl get services --sort-by=.metadata.name
# 列出 Pods,按重启次数排序
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# 列举所有 PV 持久卷,按容量排序
kubectl get pv --sort-by=.spec.capacity.storage
# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
# 检索带有 “.” 键值,例: 'ca.crt'
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果)
kubectl get node --selector='!node-role.kubernetes.io/master'
# 获取当前命名空间中正在运行的 Pods
kubectl get pods --field-selector=status.phase=Running
# 获取全部节点的 ExternalIP 地址
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
# 列出属于某个特定 RC 的 Pods 的名称
# 在转换对于 jsonpath 过于复杂的场合,"jq" 命令很有用;可以在 https://stedolan.github.io/jq/ 找到它。
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
# 显示所有 Pods 的标签(或任何其他支持标签的 Kubernetes 对象)
kubectl get pods --show-labels
# 检查哪些节点处于就绪状态
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# 不使用外部工具来输出解码后的 Secret
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'
# 列出被一个 Pod 使用的全部 Secret
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# 列举所有 Pods 中初始化容器的容器 ID(containerID)
# 可用于在清理已停止的容器时避免删除初始化容器
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# 列出事件(Events),按时间戳排序
kubectl get events --sort-by=.metadata.creationTimestamp
# 比较当前的集群状态和假定某清单被应用之后的集群状态
kubectl diff -f ./my-manifest.yaml
# 生成一个句点分隔的树,其中包含为节点返回的所有键
# 在复杂的嵌套JSON结构中定位键时非常有用
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 生成一个句点分隔的树,其中包含为pod等返回的所有键
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 假设你的 Pods 有默认的容器和默认的名字空间,并且支持 'env' 命令,可以使用以下脚本为所有 Pods 生成 ENV 变量。
# 该脚本也可用于在所有的 Pods 里运行任何受支持的命令,而不仅仅是 'env'。
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done
更新资源
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录,包括版本
kubectl rollout undo deployment/frontend # 回滚到上次部署版本
kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本
kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成
kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod
# 强制替换,删除后重建资源。会导致服务不可用。
kubectl replace --force -f ./pod.json
# 为多副本的 nginx 创建服务,使用 80 端口提供服务,连接到容器的 8000 端口。
kubectl expose rc nginx --port=80 --target-port=8000
# 将某单容器 Pod 的镜像版本(标签)更新到 v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # 添加标签
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解
kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容
部分更新资源
# 部分更新某节点
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
# 更新容器的镜像;spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
# 使用带位置数组的 JSON patch 更新容器的镜像
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
# 在带位置数组中添加元素
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
编辑资源
使用你偏爱的编辑器编辑 API 资源。
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器
对资源进行伸缩
kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本
kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2,那么将它伸缩到 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器
删除资源
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务
kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务
kubectl -n my-ns delete pod,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务
# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
与运行中的 Pods 进行交互
kubectl logs my-pod # 获取 pod 日志(标准输出)
kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志(标准输出)
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出)
kubectl logs my-pod -c my-container # 获取 Pod 容器的日志(标准输出, 多容器场景)
kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志(标准输出, 多容器场景)
kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志(标准输出, 多容器场景)
kubectl logs -f my-pod # 流式输出 Pod 的日志(标准输出)
kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志(标准输出, 多容器场景)
kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志(标准输出)
kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod
kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod
kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件
--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # 挂接到一个运行的容器中
kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000
kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令(单容器场景)
kubectl exec --stdin --tty my-pod -- /bin/sh # 使用交互 shell 访问正在运行的 Pod (一个容器场景)
kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令(多容器场景)
kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据
kubectl top pod POD_NAME --sort-by=cpu # 显示给定 Pod 的指标并且按照 'cpu' 或者 'memory' 排序
与 Deployments 和 Services 进行交互
kubectl logs deploy/my-deployment # 获取一个 Deployment 的 Pod 的日志(单容器例子)
kubectl logs deploy/my-deployment -c my-container # 获取一个 Deployment 的 Pod 的日志(多容器例子)
kubectl port-forward svc/my-service 5000 # 侦听本地端口 5000 并转发到 Service 后端端口 5000
kubectl port-forward svc/my-service 5000:my-service-port # 侦听本地端口 5000 并转发到名字为 <my-service-port> 的 Service 目标端口
kubectl port-forward deploy/my-deployment 5000:6000 # 侦听本地端口 5000 并转发到 <my-deployment> 创建的 Pod 里的端口 6000
kubectl exec deploy/my-deployment -- ls # 在 Deployment 里的第一个 Pod 的第一个容器里运行命令(单容器和多容器例子)
与节点和集群进行交互
kubectl cordon my-node # 标记 my-node 节点为不可调度
kubectl drain my-node # 对 my-node 节点进行清空操作,为节点维护做准备
kubectl uncordon my-node # 标记 my-node 节点为可以调度
kubectl top node my-node # 显示给定节点的度量值
kubectl cluster-info # 显示主控节点和服务的地址
kubectl cluster-info dump # 将当前集群状态转储到标准输出
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state
# 如果已存在具有指定键和效果的污点,则替换其值为指定值。
kubectl taint nodes foo dedicated=special-user:NoSchedule
资源类型
列出所支持的全部资源类型和它们的简称、API 组, 是否是名字空间作用域 和 Kind。
kubectl api-resources
用于探索 API 资源的其他操作:
kubectl api-resources --namespaced=true # 所有命名空间作用域的资源
kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源
kubectl api-resources -o name # 用简单格式列举所有资源(仅显示资源名称)
kubectl api-resources -o wide # 用扩展格式列举所有资源(又称 "wide" 格式)
kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源
kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源
格式化输出
要以特定格式将详细信息输出到终端窗口,将 -o
(或者 --output
)参数添加到支持的 kubectl
命令中。
输出格式 | 描述 |
---|---|
-o=custom-columns=<spec> | 使用逗号分隔的自定义列来打印表格 |
-o=custom-columns-file=<filename> | 使用 <filename> 文件中的自定义列模板打印表格 |
-o=json | 输出 JSON 格式的 API 对象 |
-o=jsonpath=<template> | 打印 jsonpath 表达式中定义的字段 |
-o=jsonpath-file=<filename> | 打印在 <filename> 文件中定义的 jsonpath 表达式所指定的字段。 |
-o=name | 仅打印资源名称而不打印其他内容 |
-o=wide | 以纯文本格式输出额外信息,对于 Pod 来说,输出中包含了节点名称 |
-o=yaml | 输出 YAML 格式的 API 对象 |
使用 -o=custom-columns
的示例:
# 集群中运行着的所有镜像
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
# 列举 default 名字空间中运行的所有镜像,按 Pod 分组
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"
# 除 "k8s.gcr.io/coredns:1.6.2" 之外的所有镜像
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
# 输出 metadata 下面的所有字段,无论 Pod 名字为何
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
有关更多示例,请参看 kubectl 参考文档。
Kubectl 日志输出详细程度和调试
Kubectl 日志输出详细程度是通过 -v
或者 --v
来控制的,参数后跟一个数字表示日志的级别。
Kubernetes 通用的日志习惯和相关的日志级别在
这里 有相应的描述。
详细程度 | 描述 |
---|---|
--v=0 | 用于那些应该 始终 对运维人员可见的信息,因为这些信息一般很有用。 |
--v=1 | 如果您不想要看到冗余信息,此值是一个合理的默认日志级别。 |
--v=2 | 输出有关服务的稳定状态的信息以及重要的日志消息,这些信息可能与系统中的重大变化有关。这是建议大多数系统设置的默认日志级别。 |
--v=3 | 包含有关系统状态变化的扩展信息。 |
--v=4 | 包含调试级别的冗余信息。 |
--v=5 | 跟踪级别的详细程度。 |
--v=6 | 显示所请求的资源。 |
--v=7 | 显示 HTTP 请求头。 |
--v=8 | 显示 HTTP 请求内容。 |
--v=9 | 显示 HTTP 请求内容而且不截断内容。 |
接下来
- 参阅 kubectl 概述,进一步了解JsonPath。
- 参阅 kubectl 选项。
- 参阅 kubectl 使用约定来理解如何在可复用的脚本中使用它。
- 查看社区中其他的 kubectl 备忘单。
6 - kubectl 的用法约定
kubectl
的推荐用法约定。
在可重用脚本中使用 kubectl
对于脚本中的稳定输出:
- 请求一个面向机器的输出格式,例如
-o name
、-o json
、-o yaml
、-o go template
或-o jsonpath
。 - 完全限定版本。例如
jobs.v1.batch/myjob
。这将确保 kubectl 不会使用其默认版本,该版本会随着时间的推移而更改。 - 不要依赖上下文、首选项或其他隐式状态。
最佳实践
kubectl run
若希望 kubectl run
满足基础设施即代码的要求:
- 使用特定版本的标签标记镜像,不要将该标签移动到新版本。例如,使用
:v1234
、v1.2.3
、r03062016-1-4
,而不是:latest
(有关详细信息,请参阅配置的最佳实践)。 - 使用基于版本控制的脚本来运行包含大量参数的镜像。
- 对于无法通过
kubectl run
参数来表示的功能特性,使用基于源码控制的配置文件,以记录要使用的功能特性。
你可以使用 --dry-run=client
参数来预览而不真正提交即将下发到集群的对象实例:
说明:所有的
kubectl run
生成器已弃用。 查阅 Kubernetes v1.17 文档中的生成器列表以及它们的用法。
生成器
你可以使用 kubectl 命令生成以下资源, kubectl create --dry-run=client -o yaml
:
clusterrole
: 创建 ClusterRole。clusterrolebinding
: 为特定的 ClusterRole 创建 ClusterRoleBinding。configmap
: 使用本地文件、目录或文本值创建 Configmap。cronjob
: 使用指定的名称创建 Cronjob。deployment
: 使用指定的名称创建 Deployment。job
: 使用指定的名称创建 Job。namespace
: 使用指定的名称创建名称空间。poddisruptionbudget
: 使用指定名称创建 Pod 干扰预算。priorityclass
: 使用指定的名称创建 Priorityclass。quota
: 使用指定的名称创建配额。role
: 使用单一规则创建角色。rolebinding
: 为特定角色或 ClusterRole 创建 RoleBinding。secret
: 使用指定的子命令创建 Secret。service
: 使用指定的子命令创建服务。serviceaccount
: 使用指定的名称创建服务帐户。
kubectl apply
- 您可以使用
kubectl apply
命令创建或更新资源。有关使用 kubectl apply 更新资源的详细信息,请参阅 Kubectl 文档。
7 - 适用于 Docker 用户的 kubectl
您可以使用 Kubernetes 命令行工具 kubectl
与 API 服务器进行交互。如果您熟悉 Docker 命令行工具,则使用 kubectl 非常简单。但是,Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令,并描述了等效的 kubectl
命令。
docker run
要运行 nginx 部署并将其暴露,请参见kubectl create deployment docker:
docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
kubectl:
# 启动运行 nginx 的 Pod
kubectl create deployment --image=nginx nginx-app
deployment.apps/nginx-app created
# add env to nginx-app
kubectl set env deployment/nginx-app DOMAIN=cluster
deployment.apps/nginx-app env updated
说明:
kubectl
命令打印创建或突变资源的类型和名称,然后可以在后续命令中使用。部署后,您可以公开新服务。
# 通过服务公开端口
kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed
在 kubectl 命令中,我们创建了一个 Deployment,这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数,默认为 1)。我们还创建了一个 service,其选择器与容器标签匹配。查看使用服务访问群集中的应用程序 获取更多信息。
默认情况下镜像会在后台运行,与 docker run -d ...
类似,如果您想在前台运行,使用 kubectl run
在前台运行 Pod:
kubectl run [-i] [--tty] --attach <name> --image=<image>
与 docker run ...
不同的是,如果指定了 --attach
,我们将连接到 stdin
,stdout
和 stderr
,而不能控制具体连接到哪个输出流(docker -a ...
)。要从容器中退出,可以输入 Ctrl + P,然后按 Ctrl + Q。
因为我们使用 Deployment 启动了容器,如果您终止连接到的进程(例如 ctrl-c
),容器将会重启,这跟 docker run -it
不同。
如果想销毁该 Deployment(和它的 pod),您需要运行 kubectl delete deployment <name>
。
docker ps
如何列出哪些正在运行?查看 kubectl get。
使用 docker 命令:
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
使用 kubectl 命令:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
docker attach
如何连接到已经运行在容器中的进程?查看 kubectl attach。
使用 docker 命令:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
docker attach 55c103fa1296
...
kubectl:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl attach -it nginx-app-5jyvm
...
要从容器中分离,可以输入 Ctrl + P,然后按 Ctrl + Q。
docker exec
如何在容器中执行命令?查看 kubectl exec。
使用 docker 命令:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296
使用 kubectl 命令:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
nginx-app-5jyvm
执行交互式命令怎么办?
使用 docker 命令:
docker exec -ti 55c103fa1296 /bin/sh
# exit
kubectl:
kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
更多信息请查看获取运行中容器的 Shell 环境。
docker logs
如何查看运行中进程的 stdout/stderr?查看 kubectl logs。
使用 docker 命令:
docker logs -f a9e
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
使用 kubectl 命令:
kubectl logs -f nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
现在是时候提一下 pod 和容器之间的细微差别了;默认情况下如果 pod 中的进程退出 pod 也不会终止,相反它将会重启该进程。这类似于 docker run 时的 --restart=always
选项, 这是主要差别。在 docker 中,进程的每个调用的输出都是被连接起来的,但是对于 kubernetes,每个调用都是分开的。要查看以前在 kubernetes 中执行的输出,请执行以下操作:
kubectl logs --previous nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
查看日志架构获取更多信息。
docker stop and docker rm
如何停止和删除运行中的进程?查看 kubectl delete。
使用 docker 命令:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
docker stop a9ec34d98787
a9ec34d98787
docker rm a9ec34d98787
a9ec34d98787
使用 kubectl 命令:
kubectl get deployment nginx-app
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-app 1 1 1 1 2m
kubectl get po -l app=nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l app=nginx-app
# Return nothing
说明:请注意,我们不直接删除 pod。使用 kubectl 命令,我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod,Deployment 将会重新创建该 pod。
docker login
在 kubectl 中没有对 docker login
的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes,请参阅使用私有镜像仓库。
docker version
如何查看客户端和服务端的版本?查看 kubectl version。
使用 docker 命令:
docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64
使用 kubectl 命令:
kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
docker info
如何获取有关环境和配置的各种信息?查看 kubectl cluster-info。
使用 docker 命令:
docker info
Containers: 40
Images: 168
Storage Driver: aufs
Root Dir: /usr/local/google/docker/aufs
Backing Filesystem: extfs
Dirs: 248
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support
使用 kubectl 命令:
kubectl cluster-info
Kubernetes master is running at https://108.59.85.141
KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy