【Kurbernetes资源管理】陈述式资源管理方式

一、 理论部分

1.1 管理K8s资源的基本方法

1.1.1 陈述式资源管理方式

主要依赖命令行工具kubectl进行管理，可以理解为使用一条命令和参数选项实现资源的管理操作。

1.1.2声明式资源管理方式

主要依赖统一资源配置清单进行管理，可以理解为使用yaml配置文件的定义来实现资源的管理操作。

1.1.3 GUI式资源管理方法

主要依赖图形化操作界面进行管理。

1.2 陈述式资源管理方式

K8s中文文档 ：Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区

1.2.1 Kubelet工具简介

Kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口。

Kubectl 是官方的CLI命令行工具，用于与 apiserver 进行通信，将用户在命令行输入的命令，组织并转化为 apiserver 能识别的信息，进而实现管理 k8s 各种资源。

#kubectl 的命令大全
kubectl --help-h 

对资源的增、删、查操作比较方便，但对改的操作就不容易了

#查看k8s版本信息
kubectl version

#查看资源对象简写
kubectl api-resources

#查看集群信息
kubectl cluster-info

#node节点查看日志
journalctl -u kubectl -f

1.2.2 kubectl 的基本语法

kubectl [command] [Type] [NAME] [flags]

语法构成部分	名称	功能	举个例子
command	子命令	用于操作kubernetes集群资源对象的命令	例如：create, delete, describe, get, apply等等
TYPE	资源对象的类型	区分大小写,能以单数，复数或者简写形式表示
NAME	资源对象的名称	区分大小写,如果不指定名称，系统则将返回属于TYPE的全部对象的列表
flags	子命令的可选参数

1.2.3 Kubectl工具的自动补全功能

Kurbernetes在2.0 版本后就增加kubectl自动补全功能。

#二进制安装的k8s,kubectl工具没有自动补全功能(其他方式安装的未验证)
#可以使用以下方式开启命令自动补全
vim /etc/bashrcsource <(kubectl completion bash)

1.3 Kubernetes Service

遇到的问题

1）Pod 的 IP 不固定，Pod可能会重建

2）一组 Pod 实例之间总会有负载均衡的需求

简介

Kubernetes Service（Kubernetes 服务）是一种虚拟网络抽象，它定义了一组完成特定功能的 Pod 的策略，并为这组 Pod 提供了稳定的访问端点。

服务可用于将应用程序暴露给集群内外部的其他组件，从而实现应用程序间的通信。

Kubernetes Service 提供了以下主要功能：

1）透明的服务发现：通过为服务分配唯一的 DNS 名称，可以轻松地在集群内进行服务发现，而不需要了解服务所在的具体 Pod。

2）负载均衡：服务为后端 Pod 提供负载均衡，将流量均匀地分发给各个 Pod，从而提高应用程序的可用性和可扩展性。

3）稳定的网络端点：每个服务都有一个虚拟 IP 地址和端口，可以稳定地与服务进行通信，而不受底层 Pod 的变化影响。

1.4 Service 的类型(记下来)

1）ClusterIP

Service的默认类型，提供一个集群内部的虚拟IP（Cluster IP:Port)，用于Kurbernetes集群内部访问。

2）NodePort

会在每个node节点上开启一个端口，K8S集群内部和外部用户都可以通过NodeIP:NodePort访问service并转发给其关联的Pod。

每个端口只能是一种服务，端口范围只能是 30000-32767。

3）LoadBalancer

使用云负载设备和service节点，再通过nodeIP:nodePort访问service并转发给其关联的Pod。

4）ExternalName

将service名称映射到一个DNS域名上，相当于DNS服务的CNAME记录，用于让Pod去访问集群外部的资源。

它本身没有绑定任何的资源。

1.5 Service的端点类型

Service是通过标签选择器绑定Pod的标签来关联Pod的端点（Endpoint)。

1）Port

Service 的ClusterIP 使用的端口

2） NodePort

在NodePort类型的service定义的端口，在每个node节点上开启的端口，即 nodeIP 使用的端口，默认范围为30000~32767

3）TargetPort

使用云负载设备和service做映射，外部用户通过云负载设备即可将请求转发到node节点，再通过nodeIP:nodePort访问service并转发给其关联的Pod。

4）ContainerPort

相当于给一个外部地址做别名，集群内的Pod可以通过这个service访问相关的外部服务。8875

K8S集群内部的客户端可以通过  http://clusterIP:port  -->  podIP:containerPortK8S集群外部的客户端可以通过  http://nodeIP:nodePort -->  podIP:containerPort

1.6 补充知识，各种IP

1.Node IP

Node IP 是在节点的基础网络上使用的唯一标识符。

Node IP 扮演了连接集群内部和外部网络的网关作用，所有经过 Node 的网络流量都会通过 Node IP，这个 IP 地址通常称为节点 IP 或主机 IP。

Kubernetes 中的每个 Pod 都运行在一个 Node 上，并可以访问 Node IP。

因此，如果需要连接到集群外部的服务，或者需要在 Pod 中访问互联网上的某些资源，可以使用 Node IP 进行通信。

2.Pod IP

Pod IP 是在容器网络内部使用的唯一标识符。

在Kubernetes中，每个Pod都有一个IP地址，这个IP地址是由Kubernetes集群内部的CNI插件分配的。

Pod的IP地址只在集群内部有效，并在容器网络中用于相互通信，通过访问Pod的IP地址，可以从集群内部直接访问Pod中的容器。

Pod的IP地址是在Pod创建时动态分配的，如果Pod被删除并重新创建，它的IP地址也可能会改变。

因此，在配置Kubernetes Service时，应该使用Service名称（DNS名称）来标识后端Pod，而不是使用IP地址。

3.Cluster IP

Cluster IP 是一种虚拟 IP 地址，用于在集群内部访问服务（Service）或 Pod 的 IP 地址。

Cluster IP 地址仅在 Kubernetes 集群内部可用，在集群外部不可访问。

Cluster IP 地址不是与任何实际网络接口相关联的，它仅是一个虚拟地址，并且被 Kubernetes 用作服务或 Pod 的入口点，负责在 Kubernetes 集群内部路由网络流量。

二、通过陈述式资源管理方式管理资源

2.1 创建

run为一次性的创建运行，删除后不会自动生成，没有pod控制器。

create创建的，删除后还会自动生成，有pod控制器，拥有副本集控制。

2.1.1 create子命令

kubectl create [-n <命名空间>] <资源类型> <资源名称> [选项]--image=镜像 --replicas=副本数 --port=容器端口

#举个例子
kubectl create service <service-name> --tcp=<port>:<target-port>kubectl create pod <pod-name> --image=<container-image>kubectl create deployment <deployment-name> --image=<container-image>

2.1.2 run子命令

kubectl run <资源名称> --image=镜像 --replicas=副本数 --port=容器端口

2.2查看基本信息-----get子命令

#基本格式
kubectl get <resource> [-o wide|json|yaml] [-n namespace]

获取资源的相关信息，-n指定命令空间，-o指定输出格式
resource可以是具体资源名称，如pod nginx- xxx;也可以是资源类型，如pod; 或者all (仅展示几种核心资源，并不完整)--all-namespaces 或-A :表示显示所有命令空间，
--show-labels :显示所有标签
-l x:仅显示标签为x的资源
-l x=y:仅显示包含x标签，且值为y的资源

2.2.1 Kubernetes 集群组件的状态

kubectl get componentstatuses 
kubectl get cs #简写

get pods --show-labels
#查看有哪些标签，面试常问

2.2.2 命名空间

命名空间在 Kubernetes 中主要用于隔离和管理资源名称。

每个命名空间具有自己的资源名称空间，保证了资源名称的唯一性。

1.获取当前集群中所有命名空间的列表

kubectl get namespace 
kubectl get ns #简写

2.获取命名空间中的所有资源的列表

kubectl get all [-n namespace]
#不指定命名空间，则默认查看default命名空间

2.2.3 Service（服务）

kubectl get service
kubectl get svc 

2.2.4 pod信息

kubectl get pods [-n namespace] [-o wide|json|yaml]

kubectl get pods --all-namespaces -o wide

2.2.5 Node（节点）列表

kubectl get nodes

2.3 查看资源详细信息-----describe

kubectl describe [-n <命名空间>] <资源类型> <资源名称>

#举个例子
#先根据kubectl get pods -A，找到要查看的资源
kubectl describe pod etcd-master01 -n kube-system

2.4 查看日志----- logs

kubectl logs [-n <命名空间>] <Pod资源名称> [-c 容器名称] [-f] [-p]
#查看Pod容器的日志

选项	对象	功能
-n	命名空间	用于指定 Pod 所属的命名空间 如果不指定命名空间，将默认使用默认命名空间
-c	容器名称，可选的容器参数	用于指定要获取日志的容器名称 如果 Pod 中只有一个容器，可以省略此参数
-f	可选的跟踪参数	用于告诉命令持续输出日志 通过添加该参数，命令将继续监视并输出 Pod 的新日志。
-p	可选的先前参数	用于获取已经终止的 Pod 的先前日志 如果 Pod 重新创建或重新调度，该参数可以用来获取先前的日志

#举个例子
kubectl logs -n kube-system kube-proxy-76hd6

2.5 删除指定的资源-----delete

Pod没有重启的概念，重启的是容器 被自动删除和重新创建

#删除命名空间app
kubectl delete [-n <命名空间>] <资源类型> <资源名称>|--all [--force --grace-period=0]

#若pod无法删除， 总是处于terminate状态， 则要强行删除pod
kubectl delete pod <name> [-n namespace ] --force --grace-period=0

grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod。

2.6 跨主机登录容器-----exec

kubectl exec可以跨主机登录容器，docker exec 只能在容器所在主机上登录。

kubectl exec -it [-n <命名空间>] <Pod资源名称> [-c 容器名称] sh|bash

kubectl exec -it my-nginx-7576957b7b-h486t sh

2.7 replicas(副本数) -----scale

用于调整 Kubernetes 集群中 Deployment 或 StatefulSet 对象的副本数量。

kubectl scale [-n <命名空间>] <deployment|statefulset> <资源名称> --replicas=副本数

#增加副本数（扩容）
kubectl scale deployment my-nginx --replicas=5

#减少副本数（缩容）
kubectl scale deployment my-nginx --replicas=1

三、结合项目的生命周期说明

项目的生命周期：创建–>发布–>更新–>回滚–>删除

3.1 创建-----kubectl create命令

创建并运行一个或多个容器镜像。

创建一个deployment 或job 来管理容器。

kubectl create --help
kubectl create service <svc资源类型> <svc资源名称> --tcp=<clusterIP的端口:容器的端口>

#举个例子 
#启动 nginx 实例，暴露容器端口 80，设置副本数 3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3kubectl get pods
kubectl get all

3.2 发布-----kubectl expose命令

将资源暴露为新的 Service。

kubectl expose --help

kubectl expose [-n <命名空间>] deployment <资源名称> --name <自定义svc资源名称> --type <svc资源类型> --port <clusterIP的端口> --targetPort <容器的端口>ClusterIP|NodePort|LoadBalancer|ExternalName

举个例子

#为deployment的nginx创建service，
#并通过Service的80端口转发至容器的80端口上
#Service的名称为nginx-service，类型为NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

#查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide#查看关联后端的节点
kubectl get endpoints#查看 service 的描述信息
kubectl describe svc nginx

curl 10.244.1.7:80curl 192.168.2.100:31134#在master01操作 查看访问日志
kubectl logs nginx-d9d8cf5c7-h4rwq
kubectl logs nginx-d9d8cf5c7-frt7t
kubectl logs nginx-d9d8cf5c7-44qdl

3.3 更新 ----- kubectl set命令

更改现有应用资源一些信息

kubectl set --help

#更新 Kubernetes 集群中某个 Deployment 的容器镜像
kubectl set image deployment <deployment资源名称> <容器名>=<镜像名>
#更改 Kubernetes 中服务对象的标签选择器
kubectl set selector service <svc资源名称> '标签key=value'

3.3.1 举个例子

#查看当前 nginx 的版本号
curl -I http://192.168.2.100:31134

#将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15kubectl get pods,svc -o wide

#再次查看nginx版本号
curl -I 192.168.2.100:31134

3.3.2 滚动更新

滚动更新 RollingUpdate            
3 desired                 副本数期望值
25% max surge             更新时允许创建的最大副本数/比例，向上取整
25% max unavailable       更新时允许销毁的最大副本数/比例，向下取整3 * 25% = 0.75     向上取整为 1    向下取整 010 desired
25% max surge
25% max unavailable10 * 25% = 2.5   向上取整为 3    向下取整 2
（10-2）<= Pod的副本数 <= (10+3) ，即整个滚动更新过程中Pod的副本数始终会处在 8 ~ 13 之间

3.4 回滚 ----- kubectl rollout 命令

#查看指定 deployment 资源的历史记录，包括版本号、更新时间和事件
kubectl rollout history deployment <deployment资源名称>#回滚
kubectl rollout undo deployment <deployment资源名称> [--to-revision=N]指定版本回滚#状态
kubectl rollout status deployment <deployment资源名称>

举个例子

#查看历史版本
kubectl rollout history deployment/nginx #执行回滚到上一个版本
kubectl rollout undo deployment/nginx#执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1#检查回滚状态
kubectl rollout status deployment/nginx

四、发布策略

如果运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布；

如果业务对用户依赖很强，建议灰度发布；

如果是K8S平台，滚动更新是现成的方案，建议先直接使用。

4.1 蓝绿发布

概念定义：蓝绿发布是一种以最小的停机时间做服务升级的策略。需要维护的两个版本的环境分别称为 “蓝环境” 和 “绿环境”。一般当前生产流量指向环境为绿环境，而在蓝环境上部署新版本，短时间内作为测试环境。

**发布流程：**首先将一半的服务流量从负载均衡列表中移除，并且更新服务版本，验证新版本没有问题后，将生产流量指向蓝环境，然后对于老版本的绿环境进行版本升级，最后将所有服务流量加回负载均衡。

两套环境交替升级，旧版本保留一定时间便于回滚。

**优点：**1）升级过程无需停机，用户感知小；2）升级/回滚速度快。

**缺点：**浪费资源成本高

4.2 红黑发布

**概念定义：**与蓝绿发布类似，红黑发布也是通过两个环境完成软件版本的升级，将当前生产流量指向的环境称为红环境，新版本环境称为黑环境。

**发布流程：**需申请新资源用于部署黑环境，在黑环境部署新版本的服务；黑环境部署完成后，一次性将生产流量指向黑环境；释放红环境的资源。

4.3 灰度发布（金丝雀发布）

#金丝雀发布由来
以前矿工开矿，在下矿洞前需要检查下方是否有毒气，矿工们先会放一只金丝雀进去探是否有毒气体，看金丝雀能否活下来。

4.3.1 简介

概念定义：

灰度发布属于增量发布，新老版本同时为用户提供服务，主要目的是保证系统的可用性。

灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。

**发布流程：**在现有环境中部署少量服务的新版本（金丝雀），部署完成后，对线上流量进行监测，如果没有问题就对老版本服务进行全量升级。

特点：

• 用户体验影响小，灰度发布过程出现问题影响范围较小
• 新版本功能逐步发布，可以逐步评估新版服务性能、稳定性和健康状态
• 发布自动化程度不够，发布期间可能引发服务中断

4.3.2 实例

在kurbernets集群中，通过陈述式管理方式实现灰度发布。

kubectl set image deployment <deployment资源名称> <容器名>=<镜像名> && kubectl rollout pause deployment <deployment资源名称>
kubectl rollout resume deployment <deployment资源名称>

4.4 滚动发布

滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

滚动发布:按批次比例停止老版本实例，启动新版本实例

小结

陈述式资源管理方式

kubectl create [-n <命名空间>] <资源类型> <资源名称> [选项]--image=镜像 --replicas=副本数 --port=容器端口kubectl run <资源名称> --image=镜像 --replicas=副本数 --port=容器端口kubectl get [-n <命名空间>] <资源类型|all> [资源名称] [-o wide|yaml|json] [-w]#详细信息
kubectl describe [-n <命名空间>] <资源类型> <资源名称>#删除（重启）
kubectl delete [-n <命名空间>] <资源类型> <资源名称>|--all [--force --grace-period=0]立即终止Pod运行并强制删除资源
#远程登录														   
kubectl exec -it [-n <命名空间>] <Pod资源名称> [-c 容器名称] sh|bash#查看Pod容器的日志  
#-f选项，实时查看
#-p选项，查看容器终止前（重新调度前）的日志
kubectl logs [-n <命名空间>] <Pod资源名称> [-c 容器名称] [-f] [-p]#修改副本数
kubectl scale [-n <命名空间>] <deployment|statefulset> <资源名称> --replicas=副本数#暴露为新的service
kubectl expose [-n <命名空间>] deployment <资源名称> --name <自定义svc资源名称> --type <svc资源类型> --port <clusterIP的端口> --targetPort <容器的端口>ClusterIP|NodePort|LoadBalancer|ExternalNamekubectl create service <svc资源类型> <svc资源名称> --tcp=<clusterIP的端口:容器的端口>kubectl set image deployment <deployment资源名称> <容器名>=<镜像名>
kubectl set selector service <svc资源名称> '标签key=value'##回滚##
#查看指定 deployment 资源的历史记录，包括版本号、更新时间和事件
kubectl rollout history deployment <deployment资源名称>#将指定 deployment 资源回滚到先前的版本
#--to-revision=N 指定版本回滚
#不指定默认回滚到上一个版本
kubectl rollout undo deployment <deployment资源名称> [--to-revision=N]#检查指定 deployment 是否已完成部署
kubectl rollout status deployment <deployment资源名称>滚动更新 RollingUpdate            
3 desired                 副本数期望值
25% max surge             更新时允许创建的最大副本数/比例，向上取整
25% max unavailable       更新时允许销毁的最大副本数/比例，向下取整3 * 25% = 0.75     向上取整为 1    向下取整 010 desired
25% max surge
25% max unavailable10 * 25% = 2.5   向上取整为 3    向下取整 2
（10-2）<= Pod的副本数 <= (10+3) ，即整个滚动更新过程中Pod的副本数始终会处在 8 ~ 13 之间

service 的4种类型

#service 的4种类型ClusterIP：默认的service资源的类型，提供clusterIP:port供K8S集群内部访问NodePort：会在每个node节点上开启一个端口，K8S集群内部和外部用户都可以通过nodeIP:nodePort访问service并转发给其关联的PodLoadBalancer：使用云负载设备和service做映射，外部用户通过云负载设备即可将请求转发到node节点，再通过nodeIP:nodePort访问service并转发给其关联的PodExternalName：相当于给一个外部地址做别名，集群内的Pod可以通过这个service访问相关的外部服务service 是 通过 标签选择器 绑定 Pod 的标签来关联 Pod 的端点（Endpoints）

service 的端点

#service 的端点
port：service 的 clusterIP 使用的端口nodePort：在NodePort类型的service定义的端口，在每个node节点上开启的端口，即 nodeIP 使用的端口，默认范围为30000~32767targetPort：service将发送给port或nodePort的请求转发给Pod的容器端口，需与containerPort一致containerPort：创建 Pod 时所指定的容器端口K8S集群内部的客户端可以通过  http://clusterIP:port  -->  podIP:containerPort
K8S集群外部的客户端可以通过  http://nodeIP:nodePort -->  podIP:containerPort

发布策略

蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚，优点用户无感知，缺点浪费资源成本高滚动发布：按批次比例停止老版本实例，启动新版本实例灰度发布/金丝雀发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本
kubectl set image deployment <deployment资源名称> <容器名>=<镜像名> && kubectl rollout pause deployment <deployment资源名称>
kubectl rollout resume deployment <deployment资源名称>