kubectl

目录

一、陈述式资源管理方法

二、基本信息查看

2.1 基本信息查看格式

2.2 查看master节点组件状态

2.3 查看命名空间

2.4 创建/查看命名空间

2.5 删除（重启）命名空间/pod

2.6 查看资源的详细信息

2.7 创建副本控制器来启动Pod

2.8 查看指定命名空间中的pod信息

2.9 跨主机登录容器

2.10 强制删除pod

2.11 扩容/缩容

2.12 删除副本控制器

2.13 查看service所对应的端点

三、项目的生命周期结合陈述式管理方法

3.1 项目的生命周期过程

3.2 创建nginx实例（创建项目）

3.3 发布项目--kubectl expose命令

3.4 Kubernetes中的service

① service的作用

② service的type类型

③ service与pod的端口

3.5 更新项目--kubectl set 命令

3.6 回滚操作--kubectl rollout 命令

3.7 删除项目（删除控制器、service资源）

四、项目的发布方式

4.1 项目发布的方式分类

4.2 蓝绿发布

4.3 红黑发布

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

① 灰度发布的概念及特点

② 金丝雀发布示例

---

一、陈述式资源管理方法

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

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

3. kubectl 的命令大全

   • kubectl --help
   • k8s中文文档:  docs.kubernetes.org.cn/683.html

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

    #查看版本信息kubectl version
   复制代码

#查看资源对象简写（缩写）
kubectl api-resources 
复制代码

#查看集群信息（查看K8S集群的控制平面即master节点）
kubectl cluster-info复制代码

#配置kubect1自动补全：将下方内容放入到/etc/bashrc文件中
source <(kubectl completion bash)
#配置完成后使用su命令切换一次shell环境
复制代码

 

#在node节点上查看相关日志
journalctl -u kubelet -f
复制代码

 

二、基本信息查看

2.1 基本信息查看格式

kubectl get <resource> [-o wide|jason|yaml] [-n namespace]
#获取资源的相关信息
-n 指定命名空间，不使用该选项指定，则默认查看default命名空间
-o 指定输出格式
resource可以是具体的资源名称，如pod nginx-xxxx；也可以是资源类型，如pod或all（all仅展示几种核心资源，并不完整）
-all-namespace或-A：用于表示所有命名空间
-l app：仅显示标签为app的资源
-l app-nginx：仅显示包含app标签，并且值为nginx的资源
复制代码

 

 

2.2 查看master节点组件状态

kubectl get componentstatuses
kubectl get cs
#以上两条命令均可以实现查看master节点组件的健康状态
复制代码

2.3 查看命名空间

kubectl get namespaces
kubectl get ns
#以上两条命令均可以实现查看命名空间
#命名空间的作用：用于允许不同命名空间的相同类型的资源重名
复制代码

#查看default命名空间的所有资源
kubectl get all [-n default]
复制代码

 

2.4 创建/查看命名空间

kubectl create ns <命名空间名称>    #创建命名空间
kubectl get ns <命名空间名称>       #查看命名空间
复制代码

 

2.5 删除（重启）命名空间/pod

kubectl delete ns <命名空间>
#删除指定命名空间，此命令慎用，防止删除该命名空间下方所有的业务资源kubectl delete pod <pod名称> -n <pod所属命名空间>
#删除指定的pod
#若删除的pod归控制器进行管理，控制器会在删除原有pod后拉取一个新的pod，则需要删除控制器后方能实现删除pod的效果
复制代码

2.6 查看资源的详细信息

kubectl describe deployments.apps nginx-test -n kube-public
#指定命名空间为kube-public，查看该命名空间下名为nginx-test的副本控制器资源的详细信息
复制代码

 

kubectl describe pods nginx-test-795d659f45-bw7qz -n kube-public
#查看kube-public这个资源类型下的指定pod的详细信息
#若pod的状态为非Running状态，可以通过此命令查看pod创建失败的相关原因
复制代码

 

2.7 创建副本控制器来启动Pod

kubectl create deployment <指定副本控制器名称> --image=<指定需要创建的容器基于的镜像> -n <指定命名空间> [--replicas=<数字>]
#创建一个指定名称的副本控制器资源，并指定该容器基于的镜像与容器所属的命名空间
#--replicas选项用于设置容器的副本数（不加该选项默认副本数为1）
复制代码

 

2.8 查看指定命名空间中的pod信息

kubectl get pods -n kube-public
#查看命名空间kube-public下的pod信息
复制代码

 

2.9 跨主机登录容器

kubectl exec -it <容器名称> bash -n <命名空间名称> [-c 容器名称] <指定shell环境> [-- 命令内容]
#kubectl exec可以用于跨主机登录容器，而docker exec只能在容器所在的宿主机上进行登录
#想要在外部实现容器内部的命令执行命令，则在命令最后方加入[-- 命令内容]kubectl exec -it nginx-test-795d659f45-bw7qz bash -n kube-public
#进入命名空间为kube-public下的容器名称为nginx-test-795d659f45-bw7qz的容器，以bash的shell环境进入
复制代码

 

 

2.10 强制删除pod

#若pod无法删除，并且总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod名称> -n <命名空间> --force --grace-period=0
#--grace-period选项表示过度存活期，默认为30s，在删除pod之前允许pod慢慢终止在该pod上运行的容器进程，从而优雅退出，0表示立即终止pod
复制代码

2.11 扩容/缩容

#扩容示例
kubectl scale <deployment|statefulset> nginx-test --replicas=3 -n kube-public
#只有deployment和statefulset两个副本控制器可以设置调整副本数量
复制代码

#缩容示例
kubectl scale <deployment|statefulset> nginx-test --replicas=1 -n kube-public
复制代码

#查看副本个数
kubectl get rs -A
复制代码

2.12 删除副本控制器

kubectl delete deployments.apps <副本控制器名称> -n <指定命名空间>
#删除指定命名空间下的指定副本控制器
复制代码

2.13 查看service所对应的端点

#以下两种方式均可查看到service所对应的端口信息
kubectl describe svc <service名称>
#查看service资源的详细信息
kubectl get endpoints
#查看service所关联的podIP以及所对应的端口号复制代码

 

三、项目的生命周期结合陈述式管理方法

3.1 项目的生命周期过程

• 项目的生命周期过程主要分为以下几个步骤
  • 创建
  • 发布
  • 更新
  • 回滚
  • 删除

3.2 创建nginx实例（创建项目）

#启动nginx实例，暴露容器端口80，设置副本数为3
kubectl create deployment nginx-test --image=nginx:1.14 --port=80 --replicas=3
复制代码

 

3.3 发布项目--kubectl expose命令

#将资源暴露为新的service
kubectl expose deployment nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
#为deployment的nginx-test创建service，并通过service的80端口转发至容器的80端口上，service的名称为nginx-service，类型为NodePort
复制代码

 

3.4 Kubernetes中的service

① service的作用

• Kubernetes之所以需要service,一方面是因为pod的IP不是固定的(Pod可能会重建)，另一方面则是因为一组Pod实例之间总会有负载均衡的需求。
• Service通过Label Selector 实现的对一组的Pod的访问。
• 对于容器应用而言，Kubernetes 提供了基于VIP (虚拟IP)的网桥的方式访问 Service， 再由Service 重定向到相应的Pod。

② service的type类型

 

• ClusterIP：默认的service资源的类型，提供clusterIP供K8S集群内部的虚拟IP以供Pod访问
• NodePort：在每个Node节点上开启一个端口，K8S集群将会在每个Node节点上打开一个端口并且每个Node的端口都是一样的，内外的用户都可以通过Node节点的IP和NodePort（即NodeIP:NodePort）的方式访问到service。
  • 每个端口只能是一种服务，端口范围只能是30000-32767。
• LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置service的场景。通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用。
• ExternalName：相当于给一个域名做别名，Pod可以通过service访问集群外部的资源

③ service与pod的端口

• service端口

  • port： service的ClusterIP所使用的端口
  • nodePort：NodePort类型的service所定义的在每个Node节点上开启的端口（默认端口范围：30000-32767）
  • targetPort：以上port或者nodeport，所要转发到的后端Pod的容器所暴露的端口

• pod端口

  • containerPort：后端Pod的容器所使用的端口（跟targetPort保持一致）

K8S集群内部访问流向：http://ClusterIP:port -->> PodIP:containerPort

K8S集群外部访问流向：http://NodeIP:NodePort -->> PodIP:containerPort

 

 

 

3.5 更新项目--kubectl set 命令

kubectl set image deployment nginx-test nginx=nginx:1.16
#将deployment副本控制器nginx-test的镜像进行更新，将nginx的版本更新为1.16#开启另一个master节点的终端进行监听pod状态
kubectl get pods -w     #该命令可以持续监控pod容器的状态
复制代码

 

 

由上方图片可以看到，我们在更新pod（项目时），会先创建一个pod容器，等到新创建的pod容器正常运行后，会对原来的容器进行删除的操作，并且后续再创建一个新的容器，再创建的容器正常运行后，会对原来的其他容器（相当于第二个容器）进行删除的操作，按照此方式循环至所有pod全部重新创建更新完毕，这个更新方式名为滚动更新（按一定的比例进行创建新的pod容器，在新创建的pod容器成功运行后，再按一定比例删除原有的容器）

 

 

3.6 回滚操作--kubectl rollout 命令

kubectl rollout history deployment nginx-test
#查看rollout的历史记录
复制代码

 

#回滚到上一版本
kubectl rollout undo deployment nginx-test
#将控制器nginx-test回滚到上一版本
#回滚结束后，原版本序号1会变为当前版本，也就是3，原序号1版本会消失#再次使用kubectl rollout history 命令将看到以下内容
deployment.apps/nginx-test
REVISION  CHANGE-CAUSE
2         <none>      #nginx版本1.16版本
3         <none>      #nginx版本1.14版本，原序号1版本由于回滚，会变成新版本序号3#开启第二个master节点终端进行pod的跟踪查看
kubectl get pods -w 
复制代码

#查看回滚是否成功
kubectl rollout status deployment nginx-test
#若在回滚时，使用此命令，可以记录回滚的状态
复制代码

 

#指定回滚的序号
kubectl rollout undo deployment nginx-test --to-revision=2
#指定恢复到回滚序号为2的版本
#不添加参数--to-revision= ，将默认恢复到上一版本
复制代码

3.7 删除项目（删除控制器、service资源）

#删除控制器
kubectl delete deployments.apps nginx-test
#删除名为nginx-test的控制器#删除service资源
#kubectl delete svc nginx-service
#删除名为nginx-service的service资源
复制代码

 

四、项目的发布方式

4.1 项目发布的方式分类

• 在项目中常用的几种发布方式为以下几种
  • 蓝绿发布
  • 红黑发布
  • 滚动发布
  • 灰度发布（金丝雀发布）

4.2 蓝绿发布

• 概念定义：

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

• 发布流程：

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

 

• 蓝绿发布的特点
  • 升级过程无需停机，用户感知小
  • 升级过程一半资源提供服务
  • 升级/回滚速度快
  • 如果出了问题，影响面较广

4.3 红黑发布

• 概念定义：

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

• 发布流程：

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

 

• 红黑发布的特点

  • 升级过程无需停机，用户感知小
  • 短时间内需要使用双倍资源

• 与蓝绿发布相比，红黑发布充分利用了云计算的弹性伸缩的优势，实现：

  • 简化发布流程
  • 避免在升级的过程中，由于只有一半资源提供服务，而导致的系统过载问题

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

① 灰度发布的概念及特点

• 概念定义：

  • 灰度发布属于增量发布，新老版本同时为用户提供服务。灰度发布的主要目的是保证系统的可用性。每一次的线上变更都无法保证系统 100% 的无 bug，所以变更后要在线上小范围验证，等没问题再全面放开。而金丝雀发布是灰度发布的一种实现。
  • 金丝雀发布由来：以前矿工开矿，在下矿洞前需要检查下方是否有毒气，矿工们先会放一只金丝雀进去探是否有毒气体，看金丝雀能否活下来。

• 发布流程：

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

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

② 金丝雀发布示例

#创建副本控制器nginx-test，并设置副本为10个
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=10#进行端口的暴露
kubectl expose deployment nginx-test --port=80 --target-port=80
复制代码

#开启master节点的另一个终端，进行pod的跟踪
kubectl get pods -w#原终端进行副本控制器nginx-test的版本升级，将pod的镜像中的nginx版本升级为1.16版本，并且在升级完第一批pod后，立即停止升级的过程
kubectl set image deployment nginx-test nginx=nginx:1.16 && kubectl rollout pause deployment nginx-test复制代码

 

 

使用curl -I 命令访问容器IP，查看nginx服务版本号信息

 

 

#若经过测试，新版本pod所提供服务无异常，我们继续后续的其他pod的更新内容
kubectl rollout resume deployment nginx-test
#设置副本控制器继续后续更新#使用curl -I命令对ClusterIP进行访问，验证是否存在其他版本的pod
curl -I 10.103.160.63
复制代码