kubectl 资源管理命令-陈述式

目录

一、kubectl陈述式资源管理:

二、kubectl陈述式对象管理:

1.基础命令使用:

[1.1 帮助手册:](#1.1 帮助手册:)

[1.2 查看版本信息:](#1.2 查看版本信息:)

​编辑

[1.3 查看资源对象简写:](#1.3 查看资源对象简写:)

[1.4 查看集群信息:](#1.4 查看集群信息:)

[1.5 配置kubectl自动补全:](#1.5 配置kubectl自动补全:)

[1.6 node节点查看日志:](#1.6 node节点查看日志:)

2.基本信息查看:

2.1基本格式:

​编辑

[2.2 查看 master 节点状态:](#2.2 查看 master 节点状态:)

[2.3 查看命名空间:](#2.3 查看命名空间:)

[2.4 查看资源信息:](#2.4 查看资源信息:)

[3. 创建删除:](#3. 创建删除:)

注意:

[4. 登录pod中的容器:](#4. 登录pod中的容器:)

[5. 扩缩容pod控制器的pod:](#5. 扩缩容pod控制器的pod:)

6.更改

三、创建项目实例:

[1. 创建 :](#1. 创建 :)

[2. 发布:](#2. 发布:)

[2.1 service 的 type 类型:](#2.1 service 的 type 类型:)

[3. 更新:](#3. 更新:)

[3.1 查看当前 nginx 的版本号:](#3.1 查看当前 nginx 的版本号:)

[3.2 更新版本:](#3.2 更新版本:)

[3.3 滚动更新详解:](#3.3 滚动更新详解:)

[4. 回滚:](#4. 回滚:)

​编辑

[5. 删除:](#5. 删除:)

四、应用发布:

[1. 发布策略:](#1. 发布策略:)

[2. 金丝雀发布:](#2. 金丝雀发布:)

[3. 发布示例:](#3. 发布示例:)

[3.1 更新deployment的版本,并配置暂停deployment:](#3.1 更新deployment的版本,并配置暂停deployment:)

[3.2 监控更新的过程:](#3.2 监控更新的过程:)

[3.3 确保更新的pod没问题了,继续更新:](#3.3 确保更新的pod没问题了,继续更新:)

[3.4 查看最后的更新情况:](#3.4 查看最后的更新情况:)

​编辑

​编辑


一、kubectl陈述式资源管理:

  1. kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口
  2. kubectl 是官方的CLI命令行工具,用于与 apiserver 进行通信,将用户在命令行输入的命令,组织并转化为 apiserver 能识别的信息,进而实现管理 k8s 各种资源的一种有效途径

二、kubectl陈述式对象管理:

1.基础命令使用:

1.1 帮助手册:

bash 复制代码
kubectl --help

1.2 查看版本信息:

bash 复制代码
kubectl version

1.3 查看资源对象简写:

bash 复制代码
kubectl api-resources

1.4 查看集群信息:

bash 复制代码
kubectl cluster-info

1.5 配置kubectl自动补全:

bash 复制代码
source <(kubectl completion bash)  ##当前bash自动补全
或

vim /etc/bashrc        ##永久自动补全
...
source <(kubectl completion bash)
source /etc/bashrc

1.6 node节点查看日志:

bash 复制代码
journalctl -u kubelet -f

2.基本信息查看:

2.1基本格式:

bash 复制代码
kubectl get <resource> [-o wide|json|yaml] [-n namespace]
获取资源的相关信息,-n 指定命令空间,-o 指定输出格式
resource可以是具体资源名称,如pod nginx-xxx;也可以是资源类型,如pod;或者all(仅展示几种核心资源,并不完整)

-o wide|json|yaml  查看详细信息|json格式查看|yaml格式查看

2.2 查看 master 节点状态:

bash 复制代码
kubectl get componentstatuses
kubectl get cs

2.3 查看命名空间:

bash 复制代码
kubectl get namespace
kubectl get ns
//命令空间的作用:用于允许不同 命名空间 的 相同类型 的资源 重名的

2.4 查看资源信息:

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

#查看pod资源
kubectl get pods -n kube-system

#查看node节点集群的信息
kubectl get nodes

#查看deployment的pod控制器
kubectl get deployment

#查看service信息
kebectl get svc

查看pod日志
kubectl logs nginx-cdb6b5b95-fjm2x

查看pod重启前日志
kubectl logs nginx-cdb6b5b95-fjm2x -p

常用命令参数总结

-n 指定命名空间

-owide 查看命名空间的pod详细信息

-A 查看pod所有资源

--show-labels 查看pod标签信息

-l app 仅显示标签为app的资源

-l app=nginx 仅显示包含app标签,且值为nginx的资源

3. 创建删除:

注意:

  • 创建pod资源分为两种,一种为 自主式pod ,一种为 控制器pod
  • 自主式pod 创建无法指定副本数量,当pod挂掉后,不会进行重建,可直接删除。
  • 控制器pod 创建可以设置副本数量,且当pod挂掉后,pod控制器会重新创建,要想删除只能删除pod控制器。
bash 复制代码
kubectl create ns kube-wzw
#创建命名空间kube-wzw
 
kubectl delete ns kube-wzw
#删除命名空间kube-wzw
 
kubectl create deployment nginx --image=nginx --port=80 --replicas=2 -n kube-wzw
#在命名空间kube-wzw创建副本控制器(deployment)来启动pod,并创建2个副本(pod名称它会随机)
//删除它只能删除的pod控制器,删除控制器后,pod控制器下面的所有pod都会删除
###注意!!!!pod控制器,不能单独创建,基本是和创建pod一起制定创建pod控制器。
 
kubectl run nginx-wl2 --image=nginx -n kube-wzw
#直接创建自主式pod(挂掉后不会重建,没有pod控制器)
//可以直接删除这个pod,它没有pod控制器
 
kubectl describe deployment nginx -n kube-wzw
#查看nginx-ydq的pod控制器的详细信息,
 
kubectl describe pods 【pod名称】 -n kube-wzw
#查看某个pod的详细信息
 
kubectl delete deployment nginx -n kube-wzw
#删除pod控制器,(里面所有的pod都会被删除)
 
kubectl delete pod nginx-wl2 -n kube-wzw
#删除自主式pod。
 
kubectl delete pod 【pod名称】 -n 【命名空间】 --force --grace-period=0
#如pod无法删除,总是处于terminate状态,则要强行删除
//grace-period 表示过度存活期,默认30s,在删除pod之前允许POD慢慢终止其上的容器进程,从而优雅退出,0表示立即终止

4. 登录pod中的容器:

bash 复制代码
kubectl exec -it 【pod名称】 bash
#可以跨主机登录到指定的pod中的容器中,docker exec只能在容器所在主机上登录

5. 扩缩容pod控制器的pod:

bash 复制代码
kubectl scale deployment nginx --replicas=4 -n kube-wzw
#扩容
 
kubectl scale deployment nginx --replicas=2 -n kube-wzw 
#缩容

6.更改

三、创建项目实例:

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

1. 创建 :

kubectl create命令

  • 创建并运行一个或多个容器镜像。
  • 创建一个deployment 或job 来管理容器。
bash 复制代码
kubectl create deployment nginx --image=nginx --port=80 --replicas=3 -n wzw

kubectl get pods   ##查看创建的pods
kubectl get all  

#也可以直接发布
kubectl expose [-n <命名空间>] deployment <资源名称> --name <自定义svc资源名称> --type <svc资源类型> --port <clusterIP的端口> --targetPort <容器的端口>

#或者先创建                                                                                        ClusterIP|NodePort|LoadBalancer|ExternalName
kubectl create service <svc资源类型> <svc资源名称> --tcp=<clusterIP的端口:容器的端口>

#更改容器使用的镜像
kubectl set image deployment <deployment资源名称> <容器名>=<镜像名>

#更改创建的service标签
kubectl set selector service <svc资源名称> '标签key=value'

2. 发布:

kubectl expose命令
将资源暴露为新的 Service。
对于容器应用而言,Kubernetes 提供了基于 VIP(虚拟IP) 的网桥的方式访问 Service,再由 Service 重定向到相应的 Pod。

2.1 service 的 type 类型:

  • ClusterIP:提供一个集群内部的虚拟IP以供Pod访问(service默认类型)
  • NodePort:在每个Node上打开一个端口以供外部访问,Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的,通过 NodeIp:NodePort 的方式Kubernetes集群外部的程序可以访问Service。 每个端口只能是一种服务,端口范围只能是 30000-32767。
  • LoadBalancer:通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。 在service提交后,Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务,并且把被代理的Pod的IP地址配置给负载均衡服务做后端。
  • externalName:将service名称映射到一个DNS域名上,相当于DNS服务的CNAME记录,用于让Pod去访问集群外部的资源,它本身没有绑定任何的资源。

将资源暴露为新的 Service。

bash 复制代码
kubectl expose deployment nginx --target-port=80 --name=nginx-service --type=NodePort -n wzw

//查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide

//查看关联后端的节点
kubectl get endpoints

//查看 service 的描述信息
kubectl describe svc nginx

//在master01操作 查看访问日志
kubectl logs nginx-cdb6b5b95-fjm2x

3. 更新:

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

bash 复制代码
获取修改模板
kubectl set image --help

3.1 查看当前 nginx 的版本号:

bash 复制代码
curl -I 10.244.4.5

3.2 更新版本:

bash 复制代码
kubectl set image -n wzw deployment/nginx nginx=nginx:1.15

//处于动态监听 pod 状态,由于使用的是滚动更新方式,所以会先生成一个新的pod,然后删除一个旧的pod,往后依次类推
kubectl get pods -w

3.3 滚动更新详解:

bash 复制代码
kubectl get all

DESIRED:表示期望的状态是 10 个 READY 的副本

CURRENT:表示当前副本的总数: 即8 个日副本 + 5 个新副本

UP_TO-DATE:表示当前已经完成更新的副本数: 即 5个新副本

AVAILABLE:表示当前处于 READY 状态的副本数: 即8个日副本。

bash 复制代码
kubectl describe deployment/nginx

滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量

maxSurge:此参数控制滚动更新过程中副本总数的超过 DESIRED 的上限。maxSurge 可以是具体的整数(比如 3),也可以是百分百,向上取整。maxSurge 默认值为 25%。

例如,DESIRED 为 10,那么副本总数的最大值为 10 + 10 * 25% = 13,即 CURRENT 为 13。

maxUnavailable:此参数控制滚动更新过程中,不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具体的整数(比如 3),也可以是百分百,向下取整。 maxUnavailable 默认值为 25%。

例如,DESIRED 为 10,那么可用的副本数至少要为 10 - 10 * 25% = 8,即 AVAILABLE 为 8。

因此 maxSurge 值越大,初始创建的新副本数量就越多;maxUnavailable 值越大,初始销毁的旧副本数量就越多。

理想情况下,DESIRED 为 10 的滚动更新的过程应该是这样的:

首先创建 3 个新副本使副本总数达到 13 个。

然后销毁 2 个旧副本使可用的副本数降到 8 个。

当这 2 个旧副本成功销毁后,可再创建 2 个新副本,使副本总数保持为 13 个。

当新副本通过 Readiness 探测后,会使可用副本数增加,超过 8。

进而可以继续销毁更多的旧副本,使可用副本数回到 8。

旧副本的销毁使副本总数低于 13,这样就允许创建更多的新副本。

这个过程会持续进行,最终所有的旧副本都会被新副本替换,滚动更新完成。

4. 回滚:

kubectl rollout 对资源进行回滚管理

bash 复制代码
kubectl rollout --help
bash 复制代码
//查看历史版本
kubectl rollout history deployment/nginx 

//执行回滚到上一个版本
kubectl rollout undo deployment/nginx

//执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1

//检查回滚状态
kubectl rollout status deployment/nginx

5. 删除:

bash 复制代码
//删除副本控制器
kubectl delete deployment/nginx

//删除service
kubectl delete svc/nginx-service

kubectl get all

四、应用发布:

1. 发布策略:

  1. 蓝绿发布:两套环境交替升级,旧版本保留一定时间便于回滚,优点用户无感知,缺点浪费资源成本高
  2. 滚动发布:按批次比例停止老版本实例,启动新版本实例
  3. 灰度发布/金丝雀发布:根据比例将老版本升级,例如80%用户访问是老版本,20%用户访问是新版本

2. 金丝雀发布:

Deployment控制器支持自定义控制更新过程中的滚动节奏,如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。

3. 发布示例:

3.1 更新deployment的版本,并配置暂停deployment:

bash 复制代码
kubectl set image deployment/myapp-ky31 nginx=nginx:1.15 && kubectl rollout pause deployment/myapp-ky31

kubectl rollout status deployment/myapp-ky31
 #观察更新状态

3.2 监控更新的过程:

bash 复制代码
kubectl get pods -w 

3.3 确保更新的pod没问题了,继续更新:

bash 复制代码
kubectl rollout resume deployment/myapp-ky31

3.4 查看最后的更新情况:

bash 复制代码
kubectl get pods -w 

curl [-I] 10.0.0.189
curl [-I] 192.168.80.11:44847

相关推荐
木风小助理1 小时前
PostgreSQL 的范式跃迁:从关系型数据库到统一数据平台
服务器·云原生·kubernetes
阿里云云原生1 小时前
ECS 端口不通,丢包诊断看这里!阿里云 SysOM 智能诊断实战!
云原生
阿里云云原生3 小时前
从这张年度技术力量榜单里,看见阿里云从云原生到 AI 原生的进化能力和决心
云原生
阿里云云原生3 小时前
2025 智能体工程现状
云原生·llm
是一个Bug4 小时前
云原生架构
云原生·架构
BUTCHER58 小时前
【漏洞扫描】ZooKeeper 未授权访问
分布式·zookeeper·云原生
企鹅侠客8 小时前
探索Kubernetes的ServiceAccounts
云原生·容器·kubernetes
虫小宝9 小时前
淘客app容器化部署方案:Docker与Kubernetes在返利系统中的实践
docker·容器·kubernetes
bs_1019 小时前
k8s工作运维中常用命令
运维·容器·kubernetes
虫小宝9 小时前
电商返利APP容器编排实践:K8s在多环境部署中的资源调度优化
云原生·容器·kubernetes