k8s kubectl陈述式资源管理及命令详解，项目流程与发布示例

[Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区http://docs.kubernetes.org.cn/683.html](#Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区http://docs.kubernetes.org.cn/683.html)

kubectl概念

概述

用途

查看当前命名空间下所有Pods和Services的详细信息

Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区http://docs.kubernetes.org.cn/683.html

kubectl概念

概述

kubectl是Kubernetes的命令行工具，用于与Kubernetes集群进行交互和管理：

Kubernetes集群管理的唯一入口是通过调用apiserver的接口：在Kubernetes中，所有对集群资源的管理操作都是通过与apiserver进行通信来实现的。apiserver是Kubernetes的控制平面组件之一，它提供了对集群资源的访问和管理接口。
kubectl是官方的CLI命令行工具：kubectl是Kubernetes提供的命令行工具，用于与apiserver进行通信，并将用户在命令行输入的命令转化为apiserver可以理解的请求。通过kubectl，用户可以方便地管理和操作Kubernetes集群中的各种资源，如Pods、Deployments、Services等。
对资源的增、删、查操作比较方便，但对改的操作就不容易了：陈述式资源管理方法的一个特点是更加注重资源的声明和配置，而不是直接对资源进行命令式的操作。因此，对于资源的增加、删除和查询等操作，使用陈述式方法是比较方便和直观的。但是，对于已经创建的资源进行修改的操作可能相对复杂，需要通过更新资源的配置文件或使用kubectl的特定命令来实现。

用途

Pod（容器组）：Pod是Kubernetes中最小的可调度和管理的单元。它是一个或多个容器的组合，它们共享网络和存储资源，并在同一主机上运行。kubectl可以用来创建、删除、管理和监视Pod。
Deployment（部署）：Deployment是一种Kubernetes资源对象，用于定义和管理Pod的副本集。它允许您指定要运行的Pod的副本数量，并提供滚动更新和回滚功能。kubectl可以用来创建、更新、扩展和删除Deployments。
Service（服务）：Service是一种Kubernetes资源对象，用于公开Pod的网络连接。它为一组Pod提供了一个稳定的网络终结点，并允许其他应用程序通过该终结点与Pod进行通信。kubectl可以用来创建、管理和删除Services。
Namespace（命名空间）：Namespace是一种逻辑隔离机制，用于将Kubernetes集群划分为多个虚拟集群。它允许不同的团队或项目在同一集群中独立地部署和管理资源。kubectl可以用来创建、切换和管理命名空间。
ConfigMap和Secret：ConfigMap和Secret是用于存储配置数据和敏感信息的Kubernetes资源对象。ConfigMap用于存储非敏感的配置数据，而Secret用于存储敏感的凭据和密钥。kubectl可以用来创建、管理和删除ConfigMaps和Secrets。
Node（节点）：Node是Kubernetes集群中的工作节点，它是物理或虚拟机器，用于运行Pod。kubectl可以用来查看和管理集群中的节点。

kubectl语法

基本语法

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

command：指定要对一个或多个资源执行的操作，例如create、get、describe、delete等。
TYPE：指定资源类型。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，pods、pod、deployments、deployment等。
NAME：指定资源的名称。名称可以是单个资源的名称，也可以是多个资源的名称，使用逗号分隔。例如，my-pod、my-deployment等。
flags：可选的标志参数，用于指定额外的选项和配置。例如，--namespace用于指定命名空间，--selector用于根据标签选择资源等。

简单举例

创建资源：kubectl create [TYPE] [NAME]
获取资源：kubectl get [TYPE] [NAME]
描述资源：kubectl describe [TYPE] [NAME]
删除资源：kubectl delete [TYPE] [NAME]
扩展资源：kubectl scale [TYPE] [NAME] --replicas=3
应用配置文件：kubectl apply -f [FILE]
查看日志：kubectl logs [POD_NAME]
进入容器：kubectl exec -it [POD_NAME] --container [CONTAINER_NAME] -- /bin/bash

kubectl使用详解

resource可以是具体资源名称，如pod nginx-xxx；也可以是资源类型，如pod；或者all(仅展示几种核心资源，并不完整)
--all-namespaces 或 -A ：表示显示所有命令空间，
--show-labels ：显示所有标签
-l app ：仅显示标签为app的资源
-l app=nginx ：仅显示包含app标签，且值为nginx的资源

kubectl get pods: 获取所有 Pod 列表。
kubectl get services: 获取所有服务列表。
kubectl get deployments: 获取所有部署列表。
kubectl get replicasets: 获取所有副本集列表。
kubectl get nodes: 获取所有节点列表。
kubectl get componentstatuses：查看master节点状态
kubectl get namespaces: 获取所有命名空间列表。
kubectl get pv: 获取所有持久卷列表。
kubectl get pvc: 获取所有持久卷声明列表。
kubectl get configmaps: 获取所有配置映射列表。
kubectl get secrets: 获取所有密钥列表。
kubectl get all [-n default]：查看default命名空间的所有资源

用于将配置文件应用于 Kubernetes 集群中的资源。它会检查指定资源的当前状态，并根据提供的配置文件进行必要的更新

`set`：更新

kubectl set： 该命令允许直接更新资源的特定字段，而无需编辑整个配置文件。它提供了一种更为简便的方式来更新资源的某些属性。例如，可以使用 kubectl set image 来更新 Deployment 中容器的镜像版本。

示例：

kubectl set image deployment/nginx-deployment nginx=nginx:1.18

总的来说，kubectl apply 用于整体性地应用和同步配置文件，而 kubectl set 用于直接更新资源的特定字段。选择使用哪个命令取决于你的具体需求。

Kubernetes（K8s）项目的生命周期管理包括创建、部署、更新、回滚，扩展、监控和维护应用程序。可以使用Kubernetes资源对象（如Deployment、StatefulSet、DaemonSet等）来管理应用程序的生命周期。通过创建适当的配置文件（如YAML文件）并使用kubectl工具或Kubernetes API来执行操作

创建-->发布-->更新-->回滚-->删除

kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
create deployment nginx: 创建一个名为nginx的deployment。
--image=nginx:1.14: 指定使用的镜像为nginx:1.14。
--port=80: 暴露容器的端口号为80。
--replicas=3: 设置deployment的副本数为3，即创建3个相同配置的pod副本。

这个命令的效果是创建了一个名为nginx的deployment，该deployment包含3个副本（pod），每个副本都运行nginx:1.14镜像，并暴露端口80。

然后，通过以下命令查看创建的资源状态：

kubectl get pods
kubectl get all

第一条命令kubectl get pods用于查看所有的pod，而第二条命令kubectl get all用于查看所有的资源，包括pod、service、deployment等。

部署发布操作

暴露service

kubectl expose命令用于将已有的资源（如deployment）暴露为新的Service，允许其他资源访问该服务。使用kubectl expose deployment命令。

kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

expose deployment nginx: 将名为nginx的deployment暴露为新的Service。
--port=80: 指定Service的端口为80。
--target-port=80: 将Service的端口80转发至容器的端口80。
--name=nginx-service: 指定Service的名称为nginx-service。
--type=NodePort: 指定Service的类型为NodePort，意味着会在每个Node上打开一个端口以供外部访问。

这个命令的效果是创建了一个名为nginx-service的Service，该Service将deployment的nginx容器暴露在80端口上，并通过NodePort类型使得外部能够访问该Service。

service的作用

使用原因

Kubernetes需要Service的主要原因有两个：

Pod的IP不固定： 每次Pod被重建或重新调度时，它都会被分配一个新的IP地址。这意味着如果直接使用Pod的IP地址来访问服务，就需要不断更新这些IP地址，这样会增加管理和维护的复杂性。Service提供了一个稳定的虚拟IP地址，代表了一组后端Pod，使得其他应用程序可以通过这个虚拟IP来访问这组Pod，而不必关心它们的具体IP地址。
负载均衡需求： 在现代应用程序中，通常会有多个实例（副本）的服务在运行，为了有效地分发流量并确保高可用性，需要对这些实例进行负载均衡。Service提供了负载均衡功能，它会将流量动态地分发到后端Pod的不同实例上，以达到负载均衡的效果。

通过Label Selector，Service能够对一组符合特定标签的Pod进行选择，并将它们作为一个整体提供服务。这使得Service能够灵活地适应不同的部署和应用场景。

另外，Kubernetes还提供了基于VIP（虚拟IP）的网桥方式来访问Service。这意味着通过Service暴露的虚拟IP地址，Kubernetes会在内部进行网络路由，将流量重定向到相应的后端Pod上。这种方式简化了网络配置，同时提供了稳定的服务访问方式。

作用

在Kubernetes中，Service是一种抽象，用于定义一组Pod的访问方式和策略。它提供了一个稳定的入口点，以便其他应用程序可以与一组Pod进行通信，而无需了解这些Pod的具体IP地址或部署情况。Service起到了以下几个重要作用：

服务发现和负载均衡： Service为一组Pod提供了一个统一的入口点，它们可以被其他应用程序或服务发现，并且在这组Pod之间均衡地分发流量，从而实现负载均衡。
稳定的网络地址： 每个Service都有一个固定的虚拟IP地址，其他应用程序可以通过这个IP地址来访问Service提供的功能，而不必关心后端Pod的具体IP地址。这种抽象使得应用程序更加灵活和可移植。
容错和高可用性： Service与后端Pod之间的通信是动态的，如果某个Pod失败或被删除，Service会自动将流量路由到健康的Pod上，从而提高了应用程序的容错性和可用性。
简化网络配置： Service可以与其他Kubernetes对象（如Deployment、StatefulSet等）无缝集成，通过简单的声明式配置即可定义网络策略和路由规则，而无需手动配置网络路由或负载均衡器。

类型

ClusterIP：为集群内部的Pod提供一个虚拟IP地址，允许其他Pod通过该IP地址访问该服务。这是默认的Service类型。
NodePort ：在每个节点（Node）上都会打开一个端口，允许外部流量通过该端口访问Service。通过 <Node_IP>:<NodePort> 的方式可以访问Service。每个节点的端口都是一样的，范围通常在30000到32767之间。
LoadBalancer：通过云服务商提供的负载均衡器（Load Balancer）将流量负载均衡到一组Pod中。在公有云上部署时，Kubernetes会调用云服务提供商的API来创建负载均衡服务，并将被代理的Pod的IP地址配置为负载均衡服务的后端。
ExternalName：将Service的名称映射到一个外部DNS域名，允许Pod访问集群外部的资源，如外部数据库或其他服务。它本身并不绑定任何实际的资源，相当于DNS服务的CNAME记录。
Headless：无头模式的ClusterIP Service。它会为每个Pod返回一个唯一的DNS记录，而不是通过ClusterIP暴露一个单一的虚拟IP。这种模式通常用于StatefulSet中，每个Pod都需要一个唯一的标识符。

根据需要，可以选择适合的Service类型来满足不同的网络访问需求。

查看资源信息

查看当前命名空间下所有Pods和Services的详细信息

kubectl get pods,svc -o wide

这个命令是用于在Kubernetes集群中获取信息的。具体来说：

kubectl 是 Kubernetes 命令行工具。
get 是用来获取资源的操作。
pods,svc 表示获取 Pods 和 Services 这两种资源的信息。
-o wide 是输出格式的选项，表示以宽格式输出信息，包括更多的列，例如节点、IP等。

因此，这个命令的作用是获取当前命名空间下所有 Pods 和 Services 的详细信息，并以宽格式显示。

查看关联后端的节点和服务描述信息

kubectl get endpoints #查看特定服务的后端节点
kubectl describe svc nginx #获取名为 "nginx" 的服务的详细描述信息，包括关联的端点

在node节点上操作，查看负载均衡端口

yum install ipvsadm -y
ipvsadm -Ln

在节点node01和node02上安装ipvsadm工具，然后使用ipvsadm -Ln命令是用来查看Linux内核中的IPVS（IP Virtual Server）规则的。IPVS是Linux内核中的一种负载均衡技术，它可以将入站的连接流量分发到一组后端服务器上，以实现负载均衡。ipvsadm -Ln命令将显示当前的IPVS规则列表，包括虚拟服务器、后端服务器和相关的负载均衡配置信息。

然后输出是通过ipvsadm -Ln命令显示的IPVS规则列表。在这个列表中，每个条目描述了一个虚拟服务器（Virtual Server）以及其对应的后端服务器（Real Server）和相关配置信息。

每个条目包含以下信息：

Prot: 协议类型（TCP或UDP）
LocalAddress:Port: 虚拟服务器的本地地址和端口
Scheduler: 负载均衡调度算法
Flags: 标志位，通常为空或包含一些特定的标记

下面是一个示例条目的解释：

TCP 172.17.0.1:30001 rr: 这是一个TCP协议的虚拟服务器，监听在172.17.0.1的30001端口上，使用的负载均衡调度算法是rr（轮询调度算法）。

接着，每个虚拟服务器条目下面列出了其对应的后端服务器列表，包括：

RemoteAddress:Port: 后端服务器的地址和端口
Forward: 转发模式（通常是Masq）
Weight: 后端服务器的权重
ActiveConn: 活跃连接数
InActConn: 非活跃连接数

例如，-> 10.244.2.3:8443 Masq 1 0 0 表示将流量转发到IP地址为10.244.2.3、端口为8443的后端服务器，转发模式为Masq（即IP伪装），权重为1，活跃连接数为0，非活跃连接数为0。

测试负载均衡

为三个nginx的pod写入不同的测试网页，进行负载均衡测试

在每个nginx的Pod中创建一个不同的HTML文件，用于测试网页。可以通过使用kubectl exec命令进入每个Pod，然后在Pod内创建文件。

kubectl exec -it <pod_name> -- bash

在Pod内部创建HTML文件，例如：

echo "<html><body><h1>This is Nginx Pod 1</h1></body></html>" > /usr/share/nginx/html/index.html

分别为每个Pod创建不同的HTML文件。

访问clusterip和nodeport，测试负载均衡

通过clusterip访问可以看到已经实现了负载均衡

kubectl get svc -o wide：
#该命令用于获取 Kubernetes 集群中的所有服务（Services）的信息，包括服务的名称、类型、ClusterIP、NodePort、端口映射等详细信息。-o wide 选项用于显示更广泛的输出，提供更多的列，以便更详细地查看服务的配置和状态。
kubectl get nodes -o wide：
#该命令用于获取 Kubernetes 集群中所有节点（Nodes）的信息，包括节点的名称、状态、角色、内部 IP、外部 IP 等详细信息。同样，-o wide 选项用于显示更广泛的输出，以提供更详细的节点信息，包括节点的操作系统、内核版本等。
#这两个命令是用于检查和获取 Kubernetes 集群中服务和节点的状态和配置信息的常见工具。

通过nodelP加nodeport进行访问依旧能够访问到nginx网页，同时不同的测试网页内容也证明了三个pod的负载均衡

在master01节点，查看访问日志

  kubectl get pods
  kubectl logs 名

更新资源

查看并获取资源模版

kubectl set --help # 显示有关 kubectl set 命令的帮助信息
kubectl set image --help # 获取修改模版

项目中应用版本更新操作

查看当前pod中nginx版本

kubectl exec <pod_name> -- nginx -v
#将 <pod_name> 替换为您要查看的 Pod 的名称。

更新nginx版本

kubectl set image deployment/nginx nginx=nginx:1.15

kubectl set image deployment/nginx：用于更新名为 nginx 的 Deployment 中的容器镜像。
nginx=nginx:1.15：指定要更新的容器的名称（这里是 nginx）和新的镜像版本（这里是 nginx:1.15）。

通过执行此命令，将 Deployment 中的 Nginx 容器更新为版本 1.15 的镜像。

更新后，pod的ip发生改变，但clusterip和nodeip没有变化
可以使用 kubectl get pods -w 命令来动态监听 Pod 的状态变化。在执行滚动更新时，Kubernetes 会按照部署策略逐步替换旧的 Pod。
通过使用 -w 标志，命令会一直保持运行，持续监视 Pod 的状态变化，并实时显示更新的进度。会看到新的 Pod 被创建，旧的 Pod 被删除，直到所有的 Pod 都被更新为新版本。
可以运行 kubectl get pods -o wide 命令以查看更新后的 Pod 的 IP 地址
再看nginx版本号，发现已经更新为新版本

回滚

如果更新出现问题，可以使用 kubectl rollout undo deployment/nginx 命令回滚到先前的版本。

kubectl rollout history deployment/nginx
#用于查看 Deployment nginx 的历史版本记录，包括发布版本的编号、触发器和时间戳等信息。

kubectl rollout undo deployment/nginx
#执行此命令将回滚 Deployment nginx 到先前的版本，通常是上一个版本。这会触发 Kubernetes 在后台进行回滚操作。

kubectl rollout undo deployment/nginx --to-revision=1
#执行此命令将回滚 Deployment nginx 到指定的版本，通过 --to-revision 参数指定要回滚到的特定版本编号。

kubectl rollout status deployment/nginx
#用于检查 Deployment nginx 的回滚状态，以确保回滚操作已成功完成。

根据输出，Deployment nginx 目前有两个版本的历史记录：

Revision 1: 第一个版本，原始的部署。
Revision 2: 目前的版本，是由于更新或其他更改而产生的。

在这种情况下，可以执行回滚命令将 Deployment nginx 回滚到 Revision 1（先前的版本）或者到 Revision 2（当前版本）。

项目删除操作

kubectl delete deployment/nginx
#删除名为 nginx 的 Deployment，该命令将停止并删除该 Deployment 下的所有 Pods。

kubectl delete svc/nginx-service
#删除名为 nginx-service 的 Service，该命令将删除该 Service。

kubectl get all 
#命令用于列出所有资源的当前状态，包括 Pods、Services、Deployments 等。执行这条命令后，将看到删除操作的效果，相关的资源将不再显示在列表中。

删除步骤

确定要删除的资源类型：根据需求，确定要删除的资源类型，如 Pod、Deployment、Service 等。
列出要删除的资源 ：执行 kubectl get <resource_type> 命令，列出要删除的资源，以确保选择了正确的资源。
执行删除操作 ：使用 kubectl delete <resource_type> <resource_name> 命令来删除资源。将 <resource_type> 替换为资源类型，如 Pod、Deployment、Service 等，将 <resource_name> 替换为要删除的资源的名称。
验证删除 ：执行 kubectl get <resource_type> 命令，确保要删除的资源已被成功删除。
示例步骤：
删除 Deployment：kubectl delete deployment nginx
删除 Service：kubectl delete service nginx-service
删除 Pod：kubectl delete pod nginx-pod

项目发布的几种方式

方式

蓝绿部署（Blue-Green Deployment）： 在新旧版本之间切换，保持两个环境，一个用于稳定的线上服务，另一个用于新版本的测试。
滚动发布（Rolling Deployment）： 逐步替换旧版本的实例，确保服务在整个过程中可用，降低风险。
金丝雀发布（Canary Release）： 将新版本逐步引入一小部分用户，监测性能和稳定性，然后逐渐扩大范围。
阶段发布（Phased Release）： 将新版本逐步推向不同的用户群体，以确保在全面发布之前能够及时发现和解决问题。
灰度发布（Gray Release）： 在部分流量中使用新版本，同时继续提供旧版本服务，逐步扩大新版本的覆盖范围。

发布流程

准备新版本： 确保新版本已经经过测试，并且准备好可以部署的可执行文件或代码。
选择发布方式： 根据项目需求和团队经验选择适合的发布方式，如蓝绿部署、滚动发布、金丝雀发布等。
设置环境： 准备好目标环境，包括服务器、数据库和其他依赖项，并确保环境配置正确。
部署新版本： 使用相应的部署工具，将新版本部署到目标环境中。这可能涉及上传文件、执行命令、更新数据库等操作。
监控和测试： 在新版本发布后，及时监控系统性能和稳定性，并进行必要的测试，以确保新版本没有引入新的问题。
逐步扩大范围： 根据选择的发布方式，逐步扩大新版本的覆盖范围，同时继续监控系统运行情况。
回滚处理： 如果在发布过程中出现严重问题，需要立即回滚到之前的稳定版本，并及时调查和解决问题。

举一个常用的金丝雀发布的例子

继续更新： 一旦你确认了新版本的 Pod 没有问题，可以使用 kubectl rollout resume 命令继续更新过程，让剩余的 Pod 也开始更新到新版本。

kubectl rollout resume deployment/nginx

在整个过程中，可以使用 kubectl rollout status 命令来查看 Deployment 更新的状态，以及使用 curl 命令来测试新版本的服务是否按预期运行。这种金丝雀发布的方式可以在更新过程中逐步测试新版本，最大程度地减少潜在风险。