【Kubernetes】如何使用 kubectl 操作 cluster、node、namespace、pod

在列出、描述、修改或删除其他命名空间中的对象时，需要给 kubectl 命令传递 --namespace（或 -n）选项。如果不指定命名空间，kubectl 将在当前上下文中配置的默认命名空间中执行操作。而当前上下文的命名空间和当前上下文本身都可以通过 kubectl config 命令进行更改。

要想快速切换到不同的命名空间，可以通过以下命令设置别名：

alias kcd='kubectl config set-context $(kubectl config current-context) --namespace

然后，可以使用 kcd some-namespace 在命名空间之间进行切换。

kubectl 中的双横杠 -- 代表着 kubectl 命令项的结束，在两个横杠之后的内容是指在 pod 内部里需要执行的命令，如果不使用双横杠则可能会导致结果异常和歧义错误。如果需要执行的命令并没有以横杠开始的参数，则横杠不是必需的。

? 展示 k8s 集群信息

kubectl cluster-info

? 列出所有集群节点

kubectl get nodes

? 查看节点详细信息

kubectl describe node {nodeName}

? 使用 alias k = kubectl 创建命令行别名，并添加到 ~/.bashrc 中永久保存。

? 集群中部署应用

kubectl run {applicationName} --image=fanqisoft/coreqi --port=8080 --generator=run/v1 replicationcontroller "{applicationName}" created

• --image：指定要运行的容器镜像。
• --port：告诉 Kubernetes 应用监听的端口。
• --generator：通常不会使用到它，它让 Kubernetes 创建一个 ReplicationController 而不是 Deployment。

? 列出所有 pod

kubectl get pods

? 列出所有 pod 以及运行 pod 的节点信息

kubectl get pods -o wide

? 列出所有 pod 并展示 pod 所携带的标签

kubectl get po --show-labels

? 如果只是对某些标签感兴趣，可以使用 -L 选项指定它们并将它们分别显示在自己的列中，而不是列出所有标签。

kubectl get po -L creation_method,env

? 列出指定命名空间下的 pod （如未指定则默认为 default 命名空间）

kubectl get po --namespace {namespaceName}
# -n 为 --namespace 的简写形式
kubectl get po -n {namespaceName}

• READY：显示 pod 的就绪情况

? 查看 pod 的详细信息

kubectl describe pod {podName}

? 创建一个服务对象。每个 pod 都有自己的 IP 地址，然而这个 IP 地址在集群内部进行访问的，要让 pod 能够从外部访问，需要通过服务对象公开它，要创建一个特殊的 LoadBalancer 类型的服务。因为如果你创建一个常规服务（一个 ClusterIP 服务），比如 pod，它也只能从集群内部访问，通过创建 LoadBalancer 类型的服务，将创建一个外部的负载均衡，可以通过负载均衡的公共 IP 访问 pod。

kubectl expose rc {applicationName} --type=LoadBalancer --name {serviceName} service "{serviceName}" exposed

• rc：ReplicationController 的缩写。大多数资源类型都有这样的缩写，省去输入全名的繁琐，pods 缩写 po，service 缩写 svc 等等。

? 列出集群中所有服务

kubectl get services

使用 minikube 的时候，可以通过 minikube service {serviceName} 获取可以访问服务的 IP 和端口。

? ReplicationController：ReplicationController 用于复制 pod（即创建 pod 的多个副本）并让它们保持运行，如果没有指定要运行多少个副本，则默认一个副本在运行，如果你的 pod 因为任何原因消失了，那么 ReplicationController 将会创建一个新的副本来替代它。

? 列出所有的 ReplicationController

kubectl get replicationcontrollers
kubectl get rc

• DESIRED：显示希望 ReplicationController 保持的 pod 副本数。
• CURRENT：显示当前运行的 pod 副本数。

? 增加副本数，也可以通过 kubectl edit rc {rcName} 命令编辑 replicationcontroller 描述文件的 spec.replicas 字段来变更副本数。

kubectl scale rc[replicationcontroller] {podName} --replicas=3

? 查看 ReplicationController 的附加信息

kubectl describe rc {rcName}

? 访问 minikube 的 dashboard

minikube dashboard

? 从已有的 pod 获取 YAML 或 JSON 描述文件

kubectl get po {podName} -o yaml
kubectl get po {podName} -o json

? 使用 kubectl 获取描述文件帮助

kubectl explain pods
kubectl explain pod.spec

? 使用 YAML 描述文件创建 pod

kubectl create -f kubia-manual.yaml

• kubectl create -f 命令用于从 YAML 或 JSON 文件创建任何资源（不只是 pod）

? 使用 YAML 描述文件创建 pod 并指定命名空间

kubectl create -f kubia-manual.yaml -n custom-namespace

? 查看 pod 日志（更准确的说是查看容器的日志）

kubectl logs {podName}

• 每天或者每次日志文件达到 10M 大小时，容器日志都会自动轮替。
• kubectl logs 命令仅显示最后一次轮替后的日志条目

? 如果我们的 pod 包含多个容器，在运行 kubectl logs 命令时则必须通过包含 -c {containerName} 选项来显式指定容器名称。

kubectl logs {podName} -c {containerName}

• 我们只能获取存在 pod 的日志，当 pod 被删除后，它的日志也会被删除。
• 如果我们希望在 pod 删除之后仍然可以获取其日志，则需要设置中心化的、集群范围的日志系统，将所有日志存储到中心存储中。

? kubectl logs 显示的是当前容器的日志，那么当前容器上一次奔溃的日志是无法通过该命令显示出来的，通过添加 --previous 选项来完成。必要时通过 kubectl describe po {podName} 查看上次奔溃原因。

kubectl logs {podName} --previous

? 端口转发（用于主机和 pod 之间通信），也可以使用暴露服务进行通信

kubectl port-forward kubia-manual 8888:8080

? 为已创建的 pod 添加标签

kubectl label po {podName} labelKey=labelValue

? 为已创建的 pod 修改标签（--overwrite 参数是必要的，否则 kubectl 将只打印出警告并不会更改标签，这样是为了防止我们在想要添加新标签时无意中更改了现有标签的值）

kubectl label po {podName} labelKey=labelValue --overwrite

? 使用标签选择器列出指定标签的 pod

# 列出指定标签值的 pod
kubectl get po -l labelKey=labelValue
# 列出在指定标签值范围内的 pod
kubectl get po -l labelKey in (labelValue1,labelValue2)
# 列出不在指定标签值范围内的 pod
kubectl get po -l labelKey notin (labelValue1,labelValue2)
# 列出不等于指定标签值的 pod
kubectl get po -l labelKey!=labelValue
# 列出包含指定标签的 pod，无论其值如何
kubectl get po -l labelKey
# 列出不包含指定标签的 pod（确保使用单引号来包含!labelKey,这样 bash shell 才不会解释感叹号，感叹号在 bash 中有特殊含义，表示事件指示器）
kubectl get po -l '!labelKey'
# 使用多条件
kubectl get po -l labelKey1=labelValue1,labelKey2=labelValue2

? 向节点添加标签

kubectl label node {nodeName} labelKey=labelValue

? 获取指定标签值的节点

kubectl get nodes -l labelKey=labelValue

? 向 pod 中添加注解

kubectl annotate pod {podName} annotateKey="annotateValue"

? 查看注解使用 describe 命令即可

kubectl describe pod {podName}

? 列出所有的命名空间

kubectl get ns

? 创建命名空间

# 创建一个 custom-namespace.yaml
apiVersion: v1   # 指定当前描述文件遵循 v1 版本的 KubernetesAPI
kind: Namespace  # 表示我们正在定义一个命名空间
metadata:
  name: custom-namespace  # 定义命名空间的名称

# 使用 kubectl 执行命令
kubectl create -f custom-namespace.yaml

# 还可以直接使用 kubectl 命令创建命名空间（命名空间名称不允许包含点号）
kubectl create namespace custom-namespace

? 删除命名空间（pod 将会伴随命名空间的删除而自动删除）

kubectl delete ns {namespaceName}

? 删除命名空间中的（几乎）所有资源（ReplicationController、pod、service 等将会被删除，而一些资源例如 Secret 等不会被删除，它们需要被明确的指定删除）。

kubectl delete all --all

• 命令中的第一个 all 指定正在删除所有资源类型，而 --all 选项指定将删除所有资源示例而非按照名称指定它们。
• kubectl delete all --all 命令也会删除名为 kubernetes 的 service，但它将在几分钟后自动重新创建。

? 根据 pod 名称删除 pod

kubectl delete po {podName1} {podName2}

? 根据 pod 标签输出 pod

kubectl delete po -l labelKey=labelValue

? 删除当前命名空间下的所有 pod（不会删除命名空间）

kubectl delete po --all

? 编辑 ReplicationController

kubectl edit rc {rcName}

这将在你的默认文本编辑器中打开 ReplicationController 的 YAML 配置。保存更改并退出编辑器后，kubectl 将更新 ReplicationController 并打印以下消息：replicationcontroller "kubia" edited

配置 kubectl edit 使用不同的文本编辑器可以通过设置 KUBE_EDITOR 环境变量来告诉 kubectl 使用你期望的文本编辑器。例如，如果你想使用 nano 编辑 Kubernetes 资源，请执行以下命令（或将其放入 ~/.bashrc 或等效文件中）：export KUBE_EDITOR="/usr/bin/nano"

如果未设置 KUBE_EDITOR 环境变量，则 kubectl edit 会回退到使用默认编辑器（通常通过 EDITOR 环境变量进行配置）。

? 删除 ReplicationController

当你通过 kubectl delete 删除 ReplicationController 时，pod 也会被删除。

但是由于由 ReplicationController 创建的 pod 不是 ReplicationController 的组成部分， 只是由其进行管理，因此可以只删除 ReplicationController 并保持 pod 运行。

kubectl delete rc {rcName} --cascade=false

• 使用 kubectl delete 删除 ReplicationController 时，可以通过给命令增加 --cascade=false 选项保持 pod 的运行，此时这些 pod 将独立，它们不再被管理，但我们始终可以使用适当的标签选择器创建新的 ReplicationController 并再次将它们管理起来。