这是本节的多页打印视图。
点击此处打印.
返回本页常规视图.
命令行工具 (kubectl)
Kubernetes 提供 kubectl 是使用 Kubernetes API 与 Kubernetes
集群的控制面进行通信的命令行工具。
这个工具叫做 kubectl
。
针对配置信息,kubectl
在 $HOME/.kube
目录中查找一个名为 config
的配置文件。
你可以通过设置 KUBECONFIG
环境变量或设置
--kubeconfig
参数来指定其它 kubeconfig 文件。
本文概述了 kubectl
语法和命令操作描述,并提供了常见的示例。
有关每个命令的详细信息,包括所有受支持的参数和子命令,
请参阅 kubectl 参考文档。
有关安装说明,请参见安装 kubectl;
如需快速指南,请参见备忘单。
如果你更习惯使用 docker
命令行工具,
Docker 用户的 kubectl
介绍了一些 Kubernetes 的等价命令。
语法
使用以下语法从终端窗口运行 kubectl
命令:
kubectl [command] [TYPE] [NAME] [flags]
其中 command
、TYPE
、NAME
和 flags
分别是:
-
要按类型和名称指定资源:
-
要对所有类型相同的资源进行分组,请执行以下操作: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
flags
: 指定可选的参数。例如,可以使用 -s
或 --server
参数指定
Kubernetes API 服务器的地址和端口。
注意:
从命令行指定的参数会覆盖默认值和任何相应的环境变量。
如果你需要帮助,在终端窗口中运行 kubectl help
。
集群内身份验证和命名空间覆盖
默认情况下,kubectl
命令首先确定它是否在 Pod 中运行,从而被视为在集群中运行。
它首先检查 KUBERNETES_SERVICE_HOST
和 KUBERNETES_SERVICE_PORT
环境变量以及
/var/run/secrets/kubernetes.io/serviceaccount/token
中是否存在服务帐户令牌文件。
如果三个条件都被满足,则假定在集群内进行身份验证。
为保持向后兼容性,如果在集群内身份验证期间设置了 POD_NAMESPACE
环境变量,它将覆盖服务帐户令牌中的默认命名空间。
任何依赖默认命名空间的清单或工具都会受到影响。
POD_NAMESPACE
环境变量
如果设置了 POD_NAMESPACE
环境变量,对命名空间资源的 CLI 操作对象将使用该变量值作为默认值。
例如,如果该变量设置为 seattle
,kubectl get pods
将返回 seattle
命名空间中的 Pod。
这是因为 Pod 是一个命名空间资源,且命令中没有提供命名空间。
直接使用 --namespace <value>
会覆盖此行为。
kubectl 如何处理 ServiceAccount 令牌
假设:
- 有 Kubernetes 服务帐户令牌文件挂载在
/var/run/secrets/kubernetes.io/serviceaccount/token
上,并且
- 设置了
KUBERNETES_SERVICE_HOST
环境变量,并且
- 设置了
KUBERNETES_SERVICE_PORT
环境变量,并且
- 你没有在 kubectl 命令行上明确指定命名空间。
然后 kubectl 假定它正在你的集群中运行。
kubectl 工具查找该 ServiceAccount 的命名空间
(该命名空间与 Pod 的命名空间相同)并针对该命名空间进行操作。
这与集群外运行的情况不同;
当 kubectl 在集群外运行并且你没有指定命名空间时,
kubectl 命令会针对你在客户端配置中为当前上下文设置的命名空间进行操作。
要为你的 kubectl 更改默认的命名空间,你可以使用以下命令:
kubectl config set-context --current --namespace=<namespace-name>
操作
下表包含所有 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 格式。注意 - 需要安装 kubectl-convert 插件。 |
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] |
在当前起作用的配置和文件或标准输之间作对比 (BETA) |
drain |
kubectl drain NODE [options] |
腾空节点以准备维护。 |
edit |
kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] |
使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 |
events |
kubectl events |
列举事件。 |
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 [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] |
使用策略合并流程更新资源的一个或多个字段。 |
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] |
管理资源的上线。有效的资源类型包括:Deployment、 DaemonSet 和 StatefulSet。 |
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.25.0 版本为准。)
资源名 |
缩写名 |
API 版本 |
按命名空间 |
资源类型 |
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 |
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 |
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/v1beta2 |
false |
FlowSchema |
prioritylevelconfigurations |
|
flowcontrol.apiserver.k8s.io/v1beta2 |
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 |
podsecuritypolicies |
psp |
policy/v1beta1 |
false |
PodSecurityPolicy |
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 |
输出选项
有关如何格式化或排序某些命令的输出的信息,请参阅以下章节。有关哪些命令支持不同输出选项的详细信息,
请参阅 kubectl 参考文档。
所有 kubectl
命令的默认输出格式都是人类可读的纯文本格式。要以特定格式在终端窗口输出详细信息,
可以将 -o
或 --output
参数添加到受支持的 kubectl
命令中。
语法
kubectl [command] [TYPE] [NAME] -o <output_format>
取决于具体的 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 对象。 |
示例
在此示例中,以下命令将单个 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
- 显示一个或多个资源的详细状态,默认情况下包括未初始化的资源。
# 显示名为 <pod-name> 的 Pod 的详细信息。
kubectl describe nodes <node-name>
# 显示名为 <pod-name> 的 Pod 的详细信息。
kubectl describe pods/<pod-name>
# 显示由名为 <rc-name> 的副本控制器管理的所有 Pod 的详细信息。
# 记住:副本控制器创建的任何 Pod 都以副本控制器的名称为前缀。
kubectl describe pods <rc-name>
# 描述所有的 Pod
kubectl describe pods
说明:
kubectl get
命令通常用于检索同一资源类别的一个或多个资源。
它具有丰富的参数,允许你使用 -o
或 --output
参数自定义输出格式。
你可以指定 -w
或 --watch
参数以开始监测特定对象的更新。
kubectl describe
命令更侧重于描述指定资源的许多相关方面。它可以调用对 API 服务器
的多个 API 调用来为用户构建视图。
例如,该 kubectl describe node
命令不仅检索有关节点的信息,还检索在其上运行的 Pod 的摘要,为节点生成的事件等。
kubectl delete
- 基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源来删除资源。
# 使用 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' 获取在 Pod <pod-name> 中容器 <container-name> 的输出。
kubectl exec <pod-name> -c <container-name> -- date
# 获取一个交互 TTY 并在 Pod <pod-name> 中运行 /bin/bash。默认情况下,输出来自第一个容器。
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs
- 打印 Pod 中容器的日志。
# 返回 Pod <pod-name> 的日志快照。
kubectl logs <pod-name>
# 从 Pod <pod-name> 开始流式传输日志。这类似于 'tail -f' Linux 命令。
kubectl logs -f <pod-name>
kubectl diff
- 查看集群建议更新的差异。
# “pod.json”中包含的差异资源。
kubectl diff -f pod.json
# 从标准输入读取的差异文件。
cat service.yaml | kubectl diff -f -
示例:创建和使用插件
使用以下示例来帮助你熟悉编写和使用 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
# 你可以"卸载"一个插件,只需从你的 $PATH 中删除它
sudo rm /usr/local/bin/kubectl-hello
为了查看可用的所有 kubectl
插件,你可以使用 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 命令之上构建更复杂功能的一种方法:
接下来的几个示例假设你已经将 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
接下来
1 - kubectl 备忘单
本页列举了常用的 kubectl
命令和标志。
Kubectl 自动补全
BASH
source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全,要先安装 bash-completion 包。
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在你的 bash shell 中永久地添加自动补全
你还可以在补全时为 kubectl
使用一个速记别名:
alias k=kubectl
complete -o default -F __start_kubectl k
ZSH
source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # 在你的 zsh shell 中永久地添加自动补全
关于 --all-namespaces
的一点说明
我们经常用到 --all-namespaces
参数,你应该要知道它的简写:
kubectl -A
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
kubectl config set-cluster my-cluster-name # 在 kubeconfig 中设置集群条目
# 在 kubeconfig 中配置代理服务器的 URL,以用于该客户端的请求
kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url
# 添加新的用户配置到 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
# 设置或显示 context / namespace 的短别名
# (仅适用于 bash 和 bash 兼容的 shell,在使用 kn 设置命名空间之前要先设置 current-context)
alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'
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:1.28 -- echo "Hello World"
# 创建一个打印 “Hello World” 间隔1分钟的 CronJob
kubectl create cronjob hello --image=busybox:1.28 --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:1.28
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox:1.28
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}'
# 检索一个 base64 编码的值,其中的键名应该包含减号而不是下划线。
kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/control-plane' 的结果)
kubectl get node --selector='!node-role.kubernetes.io/control-plane'
# 获取当前命名空间中正在运行的 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 events --types=Warning
# 比较当前的集群状态和假定某清单被应用之后的集群状态
kubectl diff -f ./my-manifest.yaml
# 生成一个句点分隔的树,其中包含为节点返回的所有键
# 在复杂的嵌套JSON结构中定位键时非常有用
kubectl get nodes -o json | jq -c 'paths|join(".")'
# 生成一个句点分隔的树,其中包含为pod等返回的所有键
kubectl get pods -o json | jq -c 'paths|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
# 获取一个 Deployment 的 status 子资源
kubectl get deployment nginx-deployment --subresource=status
更新资源
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 label pods my-pod new-label- # 移除标签
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" } }]'
# 通过修正 scale 子资源来更新 Deployment 的副本数
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'
编辑资源
使用你偏爱的编辑器编辑 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 unwanted --now # 删除 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
与运行中的 Pod 进行交互
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:1.28 -- sh # 以交互式 Shell 运行 Pod
kubectl run nginx --image=nginx -n mynamespace # 在 “mynamespace” 命名空间中运行单个 nginx Pod
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
# 为运行 nginx Pod 生成规约并将其写入到名为 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' 排序
从容器中复制文件和目录
kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # 将 /tmp/foo_dir 本地目录复制到远程当前命名空间中 Pod 中的 /tmp/bar_dir
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # 将 /tmp/foo 本地文件复制到远程 Pod 中特定容器的 /tmp/bar 下
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # 将 /tmp/foo 本地文件复制到远程 “my-namespace” 命名空间内指定 Pod 中的 /tmp/bar
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # 将 /tmp/foo 从远程 Pod 复制到本地 /tmp/bar
说明:
kubectl cp
要求容器镜像中存在 “tar” 二进制文件。如果 “tar” 不存在,kubectl cp
将失败。
对于进阶用例,例如符号链接、通配符扩展或保留文件权限,请考虑使用 kubectl exec
。
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # 将 /tmp/foo 本地文件复制到远程 “my-namespace” 命名空间中 pod 中的 /tmp/bar
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # 将 /tmp/foo 从远程 pod 复制到本地 /tmp/bar
与 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 get nodes -o='custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect'
# 如果已存在具有指定键和效果的污点,则替换其值为指定值。
kubectl taint nodes foo dedicated=special-user:NoSchedule
资源类型
列出所支持的全部资源类型和它们的简称、API 组, 是否是名字空间作用域 和 Kind。
用于探索 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"
# 除 "registry.k8s.io/coredns:1.6.2" 之外的所有镜像
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.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 请求内容而且不截断内容。 |
接下来
4 - JSONPath 支持
kubectl 支持 JSONPath 模板。
JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。Kubectl 使用 JSONPath 表达式来过滤 JSON 对象中的特定字段并格式化输出。
除了原始的 JSONPath 模板语法,以下函数和语法也是有效的:
- 使用双引号将 JSONPath 表达式内的文本引起来。
- 使用
range
,end
运算符来迭代列表。
- 使用负片索引后退列表。负索引不会“环绕”列表,并且只要
-index + listLength> = 0
就有效。
给定 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'
6 - 适用于 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
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
# 添加 env 到 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 中声明的副本数,默认为 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 命令:
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 命令:
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 命令:
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:
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 命令:
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 命令:
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 命令:
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 和 docker rm
如何停止和删除运行中的进程?查看 kubectl delete。
使用 Docker 命令:
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
a9ec34d98787
a9ec34d98787
使用 kubectl 命令:
kubectl get deployment nginx-app
NAME READY 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
# 什么都没有返回
说明:
请注意,我们不直接删除 Pod。使用 kubectl 命令,我们要删除拥有该 Pod 的 Deployment。
如果我们直接删除 Pod,Deployment 将会重新创建该 Pod。
docker login
在 kubectl 中没有对 docker login
的直接模拟。如果你有兴趣在私有镜像仓库中使用 Kubernetes,
请参阅使用私有镜像仓库。
docker version
如何查看客户端和服务端的版本?查看 kubectl version。
使用 Docker 命令:
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 命令:
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 命令:
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 命令:
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy