k8s概述

发布于:2024-06-16 ⋅ 阅读:(19) ⋅ 点赞:(0)

文章目录

一、什么是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、架构图

image-20240609234849902

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 支持许多容器运行环境,例如 containerdCRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

2.3、插件(Addons)

插件(Addons)

插件使用 Kubernetes 资源(DaemonSetDeployment 等)实现集群功能。 因为这些插件提供集群级别的功能,插件中命名空间域的资源属于 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.

img

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:defaultkube-systemkube-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-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - 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-0mysql-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: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默认值是 1
  minReadySeconds: 10 # 默认值是 0
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      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>