目次
一、什么是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、功能
- 容器编排：自动部署和管理容器，确保指定数目的容器副本始终运行。
- 服务发现与负载均衡：自动发现容器应用的服务，并在容器间分配网络流量。
- 自动扩展：根据CPU、内存等资源利用率自动增加或减少容器的数目。
- 存储编排：自动化管理存储卷的挂载与卸载，支持多种存储解决方案。
- 自我修复：当容器或节点失败时，自动重启容器或重新调度到其他节点。
- 密钥与配置管理：安全地存储和分发敏感信息，如密码、OAuth tokens等。
- 滚动更新与回滚：支持平滑地更新应用，同时提供一键回滚功能以应对新版本标题。
二、Kubernetes架构
1、架构图
2、核心组件
2.1、控制平面组件（Control Plane Components）
控制平面组件会为集群做出全局决议，比如资源的调度。 以及检测和响应集群事故。
2.1.1、kube-apiserver
集群中所有资源的统一访问入口；提供http Rest接口，完成集群管理，资源配额，访问控制，认证授权，以及对etcd的操作。
2.1.2、etcd
一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。保存集群中的所有资源对象的数据。是Kubernetes的存储状态数据库
etcd不仅能够提供键值数据存储，而且还为其提供了监听机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到api server。
2.1.3、kube-scheduler
负责资源调度，将新创建的pod调度到符合的节点上。监听Apiserver，查询是否有未调度的pod。
2.1.4、kube-controller-manager
集群中所有资源对象的自动化控制中央；负责pod和node的管理，常见的控制器有节点控制器，服务控制器，副本控制器，服务账户和令牌控制器等
2.2、Node组件
2.2.1、kubelet
在每个 Node 上运行，负责维护 Pod 的生命周期。从 API Server 获取 Pod 的盼望状态，与容器运行时（如 Docker）交互，管理 Pod 的创建、启动、停止，并将节点状态报告给 API Server。
2.2.2、kube-proxy
负责为Service提供cluster内部的服务发现和负载均衡，将对service的访问转发到后端的一组pod上；监听 API Server 中 Service 和 Endpoint 的变化，按需为service资源对象生成iptables或者ipvs规则，从而捕获当前service的流量并将其转发至正确的后端pod对象。
2.2.3、容器运行时（Container Runtime）
容器运行时是负责管理 Kubernetes 环境中容器的实行和生命周期。Kubernetes 支持许多容器运行环境，比方 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
2.3、插件（Addons）
插件利用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。
组件名称阐明kube-dns负责为整个集群提供DNS服务Ingress Controller为服务提供外网入口Heapster提供资源监控Dashboard提供GUIFederation提供跨可用区的集群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数量期望值。
- 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.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 <namespace_name>my-namespace
- 指定Namespace：在创建或管理资源时，可以通过-n 或 --namespace 参数指定操作的Namespace。如：
- kubectl get <resource_type>pods -n my-namespace
- 删除Namespace时需审慎，因为这会一并删除该Namespace下所有未被其他对象引用的资源。利用以下下令删除Namespace：
- kubectl delete namespace <namespace_name>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-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: 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、工作流程
- 创建PV：管理员界说并创建PV，指定存储资源的大小、访问模式、存储类型等。
- 创建PVC：开辟者或应用通过PVC声明需要的存储资源，指定存储大小、访问模式等要求。
- 绑定：Kubernetes自动将PVC与满足条件的PV绑定，或根据PVC需求动态创建PV后绑定。
- 挂载：Pod在创建时，通过引用PVC，Kubernetes会自动将PV挂载到Pod的指定路径，使Pod可以访问存储资源。
- 释放与回收：当不再需要存储资源时，删除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、显示集群的根本信息
2.2、切换到指定的上下文
- kubectl config use-context <context_name>
- kubectl get <resource_type>nodes
- kubectl describe node <node_name>
3.1、列出所有命名空间
- kubectl get <resource_type>namespaces
- kubectl create namespace <namespace_name>
- kubectl delete namespace <namespace_name>
- kubectl config set-context --current --namespace=<namespace_name>
4.1、列出指定类型的资源
- kubectl get <resource_type>
- kubectl describe <resource_type> <resource_name>
- kubectl create -f <yaml_file>
- kubectl apply -f <directory><yaml_file>
- kubectl delete <resource_type> <resource_name>
5.1、列出所有 Pod
- kubectl get <resource_type>pods
- kubectl describe pod <pod_name>
- kubectl logs <pod_name><pod_name>
- kubectl exec -it <pod_name> -- <command>
6.1、列出所有服务
- kubectl get <resource_type>services
- kubectl describe service <service_name><service_name>
- kubectl port-forward <pod_name> <host_port>:<container_port>
7.1、列出所有部署
- kubectl get <resource_type>deployments
- kubectl describe deployment <deployment_name>
- kubectl scale deployment <deployment_name> --replicas=<replica_count>
8.1、创建配置映射
- kubectl create configmap <configmap_name> --from-file=<file_path>
- kubectl create secret <secret_type> <secret_name> --from-literal=<key>=<value>
9.1、创建程度自动扩展
- kubectl autoscale deployment <deployment_name> --min=<min_replicas> --max=<max_replicas> --cpu-percent=<cpu_percentage>
- kubectl get <resource_type>hpa
- kubectl describe hpa <hpa_name>
10.1、标记节点为不可调度状态
- kubectl cordon <node_name>
- kubectl uncordon <node_name>
- kubectl drain <node_name>
11.1、从目次中递归地创建或更新所有资源
- kubectl apply -f <directory><yaml_file>
- kubectl diff -f <yaml_file>
- kubectl get <resource_type>-o yaml
- kubectl edit <resource_type> <resource_name>
12.1、列出所有命名空间中的指定类型的资源
- kubectl get <resource_type> --all-namespaces
- kubectl get <resource_type> -l =
13.1、列出所有持久卷
- kubectl get <resource_type>pv
- kubectl get <resource_type>pvc
- kubectl describe pv <pv_name>
- kubectl describe pvc <pvc_name>
14.1、显示集群组件的状态
- kubectl get <resource_type>componentstatuses
- kubectl get <resource_type>cs
- kubectl get <resource_type>nodes --watch
15.1、列出集群中的事故
- kubectl get <resource_type>events
- kubectl describe event <event_name>
15.4、显示集群中 Pod 的资源利用情况
16、实行下令和调试容器内部
16.1、在 Pod 内部实行下令
- kubectl exec -it <pod_name> -- <command>
- kubectl logs <pod_name><pod_name>
- kubectl logs <pod_name><pod_name>-f
17.1、列出所有服务
- kubectl get <resource_type>services
- kubectl describe service <service_name><service_name>
- kubectl expose deployment <deployment_name> --port=<port> --target-port=<target_port>
18.1、更新部署中容器的镜像
- kubectl set image deployment/<deployment_name> <container_name>=<new_image>
- kubectl rollout status deployment/<deployment_name>
- kubectl rollout history deployment/<deployment_name>
- kubectl rollout undo deployment/<deployment_name>
19.1、为节点添加标签
- kubectl label nodes <node_name> <label_key>=<label_value>
- kubectl label nodes <node_name> <label_key>-
- kubectl taint nodes <node_name> <taint_key>=<taint_value>:<taint_effect>
|
