k8s概述

一、什么是Kubernetes

1、官网链接

k8s中文官网：kubernetes.io

Github：github.com/kubernetes/kubernetes

2、概述

K8s，全称Kubernetes，是一个开源的容器编排和管理平台，用于自动部署、扩展和管理容器化应用程序的开源系统。Kubernetes由Google在2014年开源，基于其内部容器管理系统Borg的理念发展而来。"K8s"这个名字来源于将"ubernetes"之间的8个字母用"8"来代替的缩写形式。

k8s 本质上就是用来简化微服务的开发和部署的，关注点包括自愈和自动伸缩、调度和发布、调用链监控、配置管理、Metrics 监控、日志监控、弹性和容错、API 管理、服务安全等，k8s 将这些微服务的公共关注点以组件形式封装打包到 k8s 这个大平台中，让开发人员在开发微服务时专注于业务逻辑的实现，而不需要去特别关系微服务底层的这些公共关注点，大大简化了微服务应用的开发和部署，提高了开发效率。

3、特点

1、可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

2、可扩展: 模块化, 插件化, 可挂载, 可组合

3、自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

4、快速部署应用，快速扩展应用

5、无缝对接新的应用功能

6、节省资源，优化硬件资源的使用

4、功能

1. 容器编排：自动部署和管理容器，确保指定数量的容器副本始终运行。
2. 服务发现与负载均衡：自动发现容器应用的服务，并在容器间分配网络流量。
3. 自动扩展：根据CPU、内存等资源利用率自动增加或减少容器的数量。
4. 存储编排：自动化管理存储卷的挂载与卸载，支持多种存储解决方案。
5. 自我修复：当容器或节点失败时，自动重启容器或重新调度到其他节点。
6. 密钥与配置管理：安全地存储和分发敏感信息，如密码、OAuth tokens等。
7. 滚动更新与回滚：支持平滑地更新应用，同时提供一键回滚功能以应对新版本问题。

二、Kubernetes架构

1、架构图

2、核心组件

2.1、控制平面组件（Control Plane Components）

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件。

2.1.1、kube-apiserver

kube-apiserver

集群中所有资源的统一访问入口；提供http Rest接口，完成集群管理，资源配额，访问控制，认证授权，以及对etcd的操作。

2.1.2、etcd

etcd

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。保存集群中的所有资源对象的数据。是Kubernetes的存储状态数据库

etcd不仅能够提供键值数据存储，而且还为其提供了监听机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到api server。

2.1.3、kube-scheduler

kube-scheduler

负责资源调度，将新创建的pod调度到合适的节点上。监听Apiserver，查询是否有未调度的pod。

2.1.4、kube-controller-manager

kube-controller-manager

集群中所有资源对象的自动化控制中心；负责pod和node的管理，常见的控制器有节点控制器，服务控制器，副本控制器，服务账户和令牌控制器等

2.2、Node组件

2.2.1、kubelet

kubelet

在每个 Node 上运行，负责维护 Pod 的生命周期。从 API Server 获取 Pod 的期望状态，与容器运行时（如 Docker）交互，管理 Pod 的创建、启动、停止，并将节点状态报告给 API Server。

2.2.2、kube-proxy

kube-proxy

负责为Service提供cluster内部的服务发现和负载均衡，将对service的访问转发到后端的一组pod上；监听 API Server 中 Service 和 Endpoint 的变化，按需为service资源对象生成iptables或者ipvs规则，从而捕获当前service的流量并将其转发至正确的后端pod对象。

2.2.3、容器运行时（Container Runtime）

容器运行时（Container Runtime）

容器运行时是负责管理 Kubernetes 环境中容器的执行和生命周期。Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

2.3、插件（Addons）

插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

组件名称	说明
kube-dns	负责为整个集群提供DNS服务
Ingress Controller	为服务提供外网入口
Heapster	提供资源监控
Dashboard	提供GUI
Federation	提供跨可用区的集群
Fluentd-elasticsearch	提供集群日志采集、存储与查询

3、Kubernetes核心概念

3.1、pod

3.1.1、概述

Pod 是 Kubernetes 中最小的调度和管理单元，它代表着集群中运行的一个或多个容器实例。在一个 Pod 中，所有容器共享相同的网络命名空间、进程命名空间和存储卷，因此它们可以互相通信和共享数据。Pod 可以通过控制器进行创建、扩缩容和更新等操作。

同一个Pod下的多个容器共用一个IP,所以不能出现重复的端口号.一个Pod下的多个容器可以使用localhost加端口号的方式来访问对方的端口.理论上就是创建了一系列独立的Linux Namespace,然后同一个Pod下的所有容器都使用这个Linux Namespace.

3.1.2、pod生命周期

pod生命周期有的5种状态（也称5种相位）

• Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；
• Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；
• Succeed（成功）：Pod内所有容器均已退出，且不会再重启；
• Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态
• Unknown（未知）：某于某种原因api-server无法获取该pod的状态，可能由于网络通行问题导致；

3.1.4、pod状态

• ContainerCreating（容器正在创建）：容器正在创建中
• Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；
• Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；
• MatchNodeSelector （匹配节点选择器）：Pod正在等待被调度到匹配其nodeSelector的节点上，当一个Pod定义有节点选择器但没有任何节点存在指定的标签时，Pod将处于“MatchNodeSelector”状态。
• ErrImagePull（镜像拉取异常）: 这个错误表示Kubernetes无法从指定的镜像仓库拉取镜像。可能的原因有很多，比如网络问题、镜像名称或标签错误、或者没有权限访问这个镜像仓库等。
• ImagePullBackOff（镜像拉取异常）: 这个错误表示Kubernetes尝试拉取镜像，但是失败了，然后它回滚了之前的操作。这通常是因为镜像仓库的问题，比如网络问题、镜像不存在、或者没有权限访问这个镜像仓库等。
• Error（pod异常）：可能是容器运行时异常
  CrashLoopBackOff（崩溃重启） ：Pod正在经历一个无限循环的崩溃和重启过程。
• Succeed（成功）：Pod内所有容器均已退出，且不会再重启；
• Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态
• Unknown（未知）：某于某种原因api-server无法获取该pod的状态，可能由于网络通行问题导致；

3.1.5、pod创建过程

使用kubectl run命令创建的pod

1、首先，用户通过kubectl或其他api客户端工具提交需要创建的pod信息给api-server；2、api-server验证客户端的用户权限信息，验证通过开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；3、api-server开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪api-server上的变动；4、scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机，并将结果信息更新至api-server；5、node节点上的kubelet通过watch机制跟踪api-server发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈api-server；6、api-server将收到的pod状态信息存入etcd中。

使用deployment来创建pod

1、首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；2、api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，这样api-server会知道是哪个用户请求，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中，然后返回确认信息给客户端。（仅返回创建的信息并不是返回是否成功创建的结果）3、api-server开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪api-server上的变动。4、controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。5、接着调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪api-server上的变动，发现有未调度的Pod，则根据内部算法、节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定到该节点，将信息反馈给api-server。6、kubelet组件布署于Node之上，它也是通过watch机制跟踪api-server上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。7、Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。

3.1.6、pod终止过程

1、用户向api-server发送删除pod对象的命令；2、api-server中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；3、将pod标记为terminating状态；4、kubectl通过watch机制监听api-server，监控到pod对象为terminating状态了就会启动pod关闭过程；5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会以同步的方式启动执行；7、pod对象中的容器进程收到停止信息；8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；9、kubelet请求api-server将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。

3.2、Service

3.2.1、概述

Kubernetes 中 Service 是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。

Service 是 Kubernetes 中用于提供内部负载均衡和服务发现的组件，它可以将同一个应用程序的不同副本暴露在集群内部，并为这些副本提供唯一的虚拟 IP 地址和 DNS 域名。Service 可以通过控制器进行创建、更新和删除操作。

3.2.2、service的类型

一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。

• ClusterIP：表示service仅供集群内部使用,默认值就是ClusterIP类型
• NodePort：表示service可以对外访问应用,会在每个节点上暴露一个端口,这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了
• LoadBalancer：表示service对外访问应用,这种类型的service是公有云环境下的service,此模式需要外部云厂商的支持,需要有一个公网IP地址
• ExternalName：这种类型的service会把集群外部的服务引入集群内部,这样集群内直接访问service就可以间接的使用集群外部服务了

3.3、RC

3.3.1、概述

应用托管在k8s之后,k8s需要保证应用能够持续运行,这就是RC的工作内容。它会确保无论任何时间k8s中都有指定数量的Pod在运行.在此基础上,RC还提供了一些更高级的特性,比如弹性伸缩、滚动升级等。

3.3.2、功能

• 弹性伸缩
  • 弹性伸缩是指适应负载的变化,以弹性可伸缩的方式提供资源.反映到k8s中,使之可以根据负载的高低动态调整Pod的副本数量.例如在双十一将Pod数量调整为100,双十一结束后数量调整为10.
• 滚动升级
  • 滚动升级是一种平滑过渡的升级方式,通过逐步替换的策略,来保证系统的整体稳定性,在初始升级的时候就可以及时发现问题并进行调整,以保证问题的影响程度不会被扩大.回退操作通过滚动升级的逆操作即可完成.

3.4、Namespace

3.4.1、概述

Namespace 是一种将集群资源进行逻辑隔离的方法，允许将不同的资源（如Pods、Services、Deployments等）分组在一起，并为这些资源提供一个唯一的、可区分的作用域。Namespace有助于实现多租户环境、团队间的工作隔离以及资源的组织和管理。

Namespace中包含的资源通常有：Pod、Service和RC等.但是一些较底层的资源并不属于任何一个Namespace。如Node、 PersistentVolume。同一个Namespace下的资源名称必须是唯一的,但是 不同Namespace下的资源名称可以重复。

3.4.2、默认提供的三个Namespace

Kubernetes 默认提供三个Namespace：default、kube-system 和 kube-public。

• default 是没有明确指定Namespace时资源被创建的地方；
• kube-system 通常包含集群的核心组件和服务；
• kube-public 是一个可读的Namespace，用于存放希望集群内所有用户都能访问的公共资源。

3.4.3、基本操作

• 创建Namespace：可以通过YAML配置文件或者直接使用kubectl命令来创建Namespace。例如，使用命令创建名为my-namespace的Namespace：

  kubectl create namespace my-namespace
  

• 指定Namespace：在创建或管理资源时，可以通过-n 或 --namespace 参数指定操作的Namespace。如：

  kubectl get pods -n my-namespace
  

• 删除Namespace时需谨慎，因为这会一并删除该Namespace下所有未被其他对象引用的资源。使用以下命令删除Namespace：

  kubectl delete namespace my-namespace
  

3.5、Deployment

3.5.1、概述

Deployment 是 Kubernetes 中用于管理 Pod 副本集的控制器，Deployment自动管理关联的ReplicaSet，从而间接控制Pod的数量和状态。它可以控制一组 Pod 的创建、扩缩容和更新等操作。Deployment 支持滚动更新和回滚等功能，可以实现无缝的应用程序版本升级。

3.5.2、功能

• 滚动更新：可以逐步更新应用，先部署新版本的Pod，同时保持旧版本运行，直至所有Pod都更新到新版本。
• 自动回滚：如果检测到部署失败（比如健康检查不通过），Deployment可以自动回滚到之前的稳定版本。
• 版本控制：保留历史版本记录，方便查看和回滚到任意历史版本。
• 扩容与缩容：轻松调整应用实例数量，以应对负载变化。
• 声明式更新：通过修改Deployment的配置即可触发更新，无需手动干预每个Pod。

3.5.3、示例

其中创建了一个 ReplicaSet，负责启动三个 nginx Pod

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

• 创建名为 nginx-deployment（由 .metadata.name 字段标明）的 Deployment。 该名称将成为后续创建 ReplicaSet 和 Pod 的命名基础。
• 该 Deployment 创建一个 ReplicaSet，它创建三个（由 .spec.replicas 字段标明）Pod 副本。
• .spec.selector 字段定义所创建的 ReplicaSet 如何查找要管理的 Pod。 在这里，你选择在 Pod 模板中定义的标签（app: nginx）。 不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可。
• template字段包含以下子字段：
  • Pod 被使用 .metadata.labels 字段打上 app: nginx 标签。
  • Pod 模板规约（即 .template.spec 字段）指示 Pod 运行一个 nginx 容器， 该容器运行版本为 1.14.2 的 nginx Docker Hub 镜像。
  • 创建一个容器并使用 .spec.template.spec.containers[0].name 字段将其命名为 nginx。

3.6、StatefulSet

3.6.1、概述

StatefulSet 是一种专门用于管理有状态应用的工作负载的资源对象。与用于无状态应用的Deployment或ReplicaSet不同，StatefulSet为每个Pod提供了持久性唯一的标识符和稳定的存储，确保即使在Pod重启或规模变化时也能维持应用的状态一致性。

3.6.2、功能

• 持久身份：每个Pod都有一个唯一的、持久的标识符，通常格式为statefulset-name-ordinal（例如mysql-0、mysql-1），其中ordinal从0开始递增。这保证了Pod的可预测性和持久性，即便Pod重启或迁移，其网络标识符和存储也不会改变。
• 有序操作：StatefulSet保证Pod的创建、更新和删除按照Pod的ordinal顺序进行，这对于有状态应用（如数据库集群）来说至关重要，因为它们往往依赖于严格的初始化顺序或主从关系。
• 稳定存储：通过Persistent Volume Claims (PVCs) 实现持久化存储，确保每个Pod实例都能绑定到专属的存储资源，即使Pod重建或迁移，数据也不会丢失。
• 网络拓扑：为每个Pod提供固定的网络标识和稳定的网络接口，确保Pod间通信的一致性，这对于需要持久连接的应用场景（如分布式数据库）非常重要。

3.6.3、示例

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # 必须匹配 .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # 默认值是 1minReadySeconds: 10 # 默认值是 0template:metadata:labels:app: nginx # 必须匹配 .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: registry.k8s.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

• StatefulSet部分
• apiVersion: apps/v1 指定使用Apps API v1版本。
• kind: StatefulSet 表示这是一个有状态应用工作负载。
• metadata.name: web 给StatefulSet起名为web。
• spec
  • selector.matchLabels.app: nginx 用于选择已存在的Pods或用来验证新创建的Pods是否属于此StatefulSet，确保它们具有app: nginx标签。
  • serviceName: “nginx” 指定了关联的Service名称，这里与之前定义的Headless Service对应，用于Pod之间的稳定通信和发现。
  • replicas: 3 设置副本数量为3，即部署3个Nginx实例。
  • minReadySeconds: 10 指定Pod在被认为是就绪前至少需要保持Ready状态的时间，这里是10秒。
  • template
    • metadata.labels.app: nginx 确保每个Pod被打上正确的标签以匹配StatefulSet的selector。
    • spec
      • terminationGracePeriodSeconds: 10 容器优雅终止的等待时间，默认为30秒，这里设置为10秒。
      • containers
        • name: nginx 容器名称。
        • image: registry.k8s.io/nginx-slim:0.8 使用的Nginx Slim镜像。
        • ports.containerPort: 80 容器暴露的端口。
        • volumeMounts
          • name: www 挂载卷名称。
          • mountPath: /usr/share/nginx/html 容器内的挂载点，Nginx Web内容目录。
  • volumeClaimTemplates
    • metadata.name: www PVC模板的名称。
    • spec
      • accessodes: [“ReadWriteOnce”] PVC的访问模式，表示单个节点读写。
      • storageClassName: “my-storage-class” 指定存储类名称，用于动态分配PV。
      • resources.requests.storage: 1Gi 请求的存储容量为1GiB。

3.7、DaemonSet

3.7.1、概述

在Kubernetes（K8s）中，DaemonSet 是一种控制器资源对象，用于确保在集群的每个节点（或满足特定条件的节点）上运行一个且仅运行一个Pod实例。DaemonSet特别适用于那些需要在每个节点上部署守护进程类型的应用场景，如日志收集、监控代理、节点级安全软件等。

3.7.2、功能

• 节点覆盖性：确保集群中的每个节点（或匹配特定标签的节点）上都有一个Pod运行。当新节点加入集群时，会在该节点上自动创建相应的Pod；节点离开时，则对应的Pod会被清理。
• 单一实例：每个节点上最多只有一个DaemonSet管理的Pod实例，这与Deployment或ReplicaSet维护固定数量的Pod副本不同。
• 自动恢复：如果DaemonSet管理的Pod因某种原因被意外删除或节点故障，Kubernetes会自动在相应节点上重新创建该Pod。

3.8、PV（PersistentVolume，持久卷）

3.8.1、概述

是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

3.8.2、功能

• 静态配置：管理员手动创建PV，并定义其大小、访问模式（如ReadWriteOnce、ReadOnlyMany、ReadWriteMany）、存储类等。
• 资源抽象：PV为存储资源提供了统一的抽象，使得存储后端的差异对用户透明。
• 生命周期独立：即使使用PV的Pod被删除，PV本身不会被自动删除，除非设置了回收策略（Retain、Recycle、Delete）。

3.9、PVC（PersistentVolumeClaim，持久卷申领）

3.9.1、概述

表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）。同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以挂载为 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod）

3.9.2、功能

• 动态分配：如果不存在合适的PV，Kubernetes可以根据PVC的请求参数自动创建PV（需要存储类支持动态分配）。
• 资源请求：PVC中声明了所需的存储大小、访问模式等需求，Kubernetes会尝试找到符合条件的PV并与之绑定。
• 可移植性：PVC使得应用可以在不同节点间迁移，而存储资源随之迁移，保持数据的连续性。

3.9.3、工作流程

1. 创建PV：管理员定义并创建PV，指定存储资源的大小、访问模式、存储类型等。
2. 创建PVC：开发者或应用通过PVC声明需要的存储资源，指定存储大小、访问模式等要求。
3. 绑定：Kubernetes自动将PVC与满足条件的PV绑定，或根据PVC需求动态创建PV后绑定。
4. 挂载：Pod在创建时，通过引用PVC，Kubernetes会自动将PV挂载到Pod的指定路径，使Pod可以访问存储资源。
5. 释放与回收：当不再需要存储资源时，删除PVC，Kubernetes会根据PV的回收策略回收存储资源。

三、Kubernetes常见命令

1、kubectl 命令的语法

kubectl [command] [TYPE] [NAME] [flags]

• command: 指定要对资源执行的操作子命令。常见的命令包括 get, describe, create, apply, delete, exec, logs, rollout, 等。
• TYPE: 要操作的资源类型。Kubernetes 中的资源类型有很多，比如 pods, services, deployments, replicasets, configmaps, secrets, nodes, 等。这个字段可以是资源类型的单数、复数形式或其简写。
• NAME: 资源的名称。当你想要操作特定的资源实例时，需要指定它的名字。
• flags: 可选参数，用于进一步指定命令的行为。例如，-o wide 用于获取更多列出来的信息，--dry-run 用于查看操作的效果而不实际执行，-n NAMESPACE 用于指定操作的命名空间等。

2、集群管理命令

2.1、显示集群的基本信息

kubectl cluster-info

2.2、切换到指定的上下文

kubectl config use-context <context_name>

2.3、列出集群中的节点

kubectl get nodes

2.4、显示节点的详细信息

kubectl describe node <node_name>

3、命令空间管理命令

3.1、列出所有命名空间

kubectl get namespaces

3.2、创建一个命令空间

kubectl create namespace <namespace_name>

3.3、删除一个命令空间及其所有的资源

kubectl delete namespace <namespace_name>

3.4、设置当前上下文的命名空间

kubectl config set-context --current --namespace=<namespace_name>

4、资源查看和操作命令

4.1、列出指定类型的资源

kubectl get <resource_type>

4.2、显示指定资源的详细信息

kubectl describe <resource_type> <resource_name>

4.3、根据 YAML 文件创建资源

kubectl create -f <yaml_file>

4.4、根据 YAML 文件创建或更新资源

kubectl apply -f <yaml_file>

4.5、删除指定的资源

kubectl delete <resource_type> <resource_name>

5、Pod相关命令

5.1、列出所有 Pod

kubectl get pods

5.2、显示 Pod 的详细信息

kubectl describe pod <pod_name>

5.3、 查看 Pod 的日志

kubectl logs <pod_name>

5.4、在 Pod 内部执行命令

kubectl exec -it <pod_name> -- <command>

6、服务相关命令

6.1、列出所有服务

kubectl get services

6.2、显示服务的详细信息

kubectl describe service <service_name>

6.3、将本地端口转发到 Pod 的端口

kubectl port-forward <pod_name> <host_port>:<container_port>

7、部署相关命令

7.1、列出所有部署

kubectl get deployments

7.2、显示部署的详细信息

kubectl describe deployment <deployment_name>

7.3、扩展或缩减部署的副本数量

kubectl scale deployment <deployment_name> --replicas=<replica_count>

8、配置和密钥相关命令

8.1、创建配置映射

kubectl create configmap <configmap_name> --from-file=<file_path>

8.2、创建密钥

kubectl create secret <secret_type> <secret_name> --from-literal=<key>=<value>

9、水平自动扩展

9.1、创建水平自动扩展

kubectl autoscale deployment <deployment_name> --min=<min_replicas> --max=<max_replicas> --cpu-percent=<cpu_percentage>

9.2、列出所有水平自动扩展

kubectl get hpa

9.3、显示水平自动扩展的详细信息

kubectl describe hpa <hpa_name>

10、集群节点管理

10.1、标记节点为不可调度状态

kubectl cordon <node_name>

10.2、取消标记节点的不可调度状态

kubectl uncordon <node_name>

10.3、逐渐驱逐节点上的 Pod 并将其删除

kubectl drain <node_name>

11、配置文件操作

11.1、从目录中递归地创建或更新所有资源

kubectl apply -f <directory>

11.2、比较文件中的配置与集群中的当前配置的差异

kubectl diff -f <yaml_file>

11.3、获取资源的 YAML 配置

kubectl get -o yaml <resource_type> <resource_name>

11.4、编辑资源的配置

kubectl edit <resource_type> <resource_name>

12、高级资源查询和筛选命令

12.1、列出所有命名空间中的指定类型的资源

kubectl get <resource_type> --all-namespaces

12.2、根据标签筛选指定类型的资源

kubectl get <resource_type> -l <label_key>=<label_value>

13、持久化存储

13.1、列出所有持久卷

kubectl get pv

13.2、列出所有持久卷声明

kubectl get pvc

13.3、显示持久卷的详细信息

kubectl describe pv <pv_name>

13.4、显示持久卷声明的详细信息

kubectl describe pvc <pvc_name>

14、集群状态和健康检查命令

14.1、显示集群组件的状态

kubectl get componentstatuses

14.2、显示集群组件的状态的简写形式

kubectl get cs

14.3、实时监视节点的状态变化

kubectl get nodes --watch

15、状态和调试

15.1、列出集群中的事件

kubectl get events

15.2、显示指定事件的详细信息

kubectl describe event <event_name>

15.3、显示集群节点的资源使用情况

kubectl top nodes

15.4、显示集群中 Pod 的资源使用情况

kubectl top pods

16、执行命令和调试容器内部

16.1、在 Pod 内部执行命令

kubectl exec -it <pod_name> -- <command>

16.2、查看 Pod 的日志

kubectl logs <pod_name>

16.3、实时跟踪 Pod 的日志输出

kubectl logs -f <pod_name>

17、集群网络相关

17.1、列出所有服务

kubectl get services

17.2、显示服务的详细信息

kubectl describe service <service_name>

17.3、暴露部署的端口

kubectl expose deployment <deployment_name> --port=<port> --target-port=<target_port>

18、升级和回滚应用程序

18.1、更新部署中容器的镜像

kubectl set image deployment/<deployment_name> <container_name>=<new_image>

18.2、检查部署的滚动更新状态

kubectl rollout status deployment/<deployment_name>

18.3、查看部署的历史版本

kubectl rollout history deployment/<deployment_name>

18.4、回滚部署到先前的版本

kubectl rollout undo deployment/<deployment_name>

19、节点调度和亲和性

19.1、为节点添加标签

kubectl label nodes <node_name> <label_key>=<label_value>

19.2、删除节点上的标签

kubectl label nodes <node_name> <label_key>-

19.3、在节点上设置容忍性

kubectl taint nodes <node_name> <taint_key>=<taint_value>:<taint_effect>