kuberbetes的kubectl命令工具
kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口kubectl 是官方的CLI命令行工具,用于与 apiserver 进行通信,将用户在命令行输入的命令,组织并转化为 apiserver 能识别的信息,进而实现管理 k8s 各种资源的一种有效途径kubectl 的命令大全k8s中文文档:http://docs.kubernetes.org.cn/68
一、资源管理办法
1.1 陈述式资源管理方法:
kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口
kubectl 是官方的CLI命令行工具,用于与 apiserver 进行通信,将用户在命令行输入的命令,组织并转化为 apiserver 能识别的信息,进而实现管理 k8s 各种资源的一种有效途径
kubectl 的命令大全
kubectl --help
k8s中文文档:http://docs.kubernetes.org.cn/683.html
4.对资源的增、删、查操作比较方便,但对改的操作就不容易了
1.2 操作命令
① 查看版本信息
kubectl version
②查看资源对象简写
kubectl api-resources
③ 查看集群信息
kubectl cluster-info
④ 配置kubectl的自动补全
source <(kubectl completion bash)
vim /etc/bashrc
.....
source <(kubectl completion bash) #在底部添加
⑤ master节点查看日志
journalctl -u kubelet -f
或者直接查看日志
cat /var/log/messages
1.3 基本信息查看
kubectl get <resource> [-o wide | json | yaml] [-n namespace]
获取资源的相关信息,-n 指定命令空间,-o 指定输出格式
resource可以是具体资源名称,如pod nginx-xxx;也可以是资源类型,如pod;或者all(仅展示几种核心资源,并不完整)
--all-namespaces 或 -A :表示显示所有命令空间,
--show-labels :显示所有标签
-l app :仅显示标签为app的资源
-l app=nginx :仅显示包含app标签,且值为nginx的资源
① 查看master节点状态
kubectl get componentstatuses
kubectl get cs
② 查看命令空间命令
kubectl get namespace
kubectl get ns
③查看default命令空间的所有资源
kubectl get all [-n default]
④create创建命名空间
kubectl create ns kfc
kubectl get ns
⑤delete删除命名空间
kubectl delete namespace kfc
kubectl get ns
⑥在命名空间创建副本控制器启动pod
在命名空间kube-public创建副本控制器(deployment)来启动pod(nginx-cc)
kubectl create deployment nginx-cc --image=nginx -n kube-public
描述某个资源的详细信息
kubectl describe deployment nginx-cc -n kube-public
kubectl describe pod nginx-cc-df5946cf-c6r55 -n kube-public
第二种:
⑦ 创建pod实例
创建pod实例,有两种方法
kubectl run:用于快速运行一个新的Pod。不需要进行繁琐的添加追加,一般快速运行与测试pod
kubectl create:是一个更通用的命令,可以与其他子命令一起使用,以创建特定的资源,
例如可以通过创建Deployment来启动pod
它还可以用于从文件、目录中创建资源。如YAML或JSON文件,这些文件描述了要创建的资源
查看命名空间kube-public中的pod信息
kubectl get pods -n kube-public
kubectl exec 登录容器
kubectl exec可以跨主机登录容器,docker exec只能在容器所在主机上登录
kubectl exec -it nginx-cc-df5946cf-2n9b8 bash -n kube-public
⑧重启(删除)pod资源
由于存在deployment/rc 之类的副本控制器,删除pod也会重新拉起来
kubectl delete pod nginx-cc-xxxxx -n kube-public
删除后重新创建一个了
若pod无法删除,总是处于terminate状态,则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期,默认30s,在删除pod之前允许POD慢慢终止其上的容器进程,
从而优雅退出,0表示立即终止pod
1.4 扩容缩容
kubectl scale deployment nginx-cc --replicas=3 -n kube-public #扩容
kubectl scale deployment nginx-cc --replicas=1 -n kube-public #缩容
1.5 删除副本控制器
kubectl delete deployment nginx-cc -n kube-public
kubectl delete deployment/nginx-cc -n kube-public
二、项目的生命周期
2.1 项目的创建过程
创建--发布--更新--回滚--删除
2.2 命令
①创建命令-kubectl run
创建并运行一个或者多个容器镜像
创建一个deployment或job来管理容器
kubectl run --help
##启动 nginx 实例,暴露容器端口80,设置副本数 3
kubectl run nginx --image=nginx:1.14 --port=80 【--replicas=3】
注:【--replicas=3】 只是用老版本的k8s ,现在的新版本不能使用
kubectl get pods
kubectl get all
所以,我们可以通过kubectl expose命令,将服务对外进行发布,使其它主机,可以访问到pod实例
② expose-发布命令
将资源暴露为新的service
kubectl expose --help
为deployment(无部署状态)的nginx创建service,并通过service的80端口转发至容器的80端口上,service的名称为nginx-service,类型为NodePort
kubectl expose pod nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
Kubernetes之所以需要Service, 一方面是因为Pod的IP 不是固定的(Pod可能会重建),另一方面则是因为一组Pod实例之间总会有负载均衡的需求。
Service通过label Selector实现的对一组的Pod的访问。
对于容器应用而言,Kubernetes 提供了基于VIP (虚拟IP)的网桥的方式访问 Service, 再由Service 重定向到相应的Pod。
service的类型:
1、ClusterIP:提供一个集群内部的虚拟IP以供Pod访问( service默认类型
2、NodePort:在每个Node.上打开一个端口以供外部访问,Kubernetes将会在每个Node.上打开一个端口并且每个Node的端口都是一样的,通过NodeIp:NodePort的方式Kubernetes集群外部的程序可以访问Service。
注:每个端口只能是一种服务,端口范围只能是30000-32767
3、LoadBalancer:通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。
③查看pod网络状态详细信息和service暴露的端口
kubectl get pods,svc -o wide
④查看关联后端的节点
⑤查看service的描述信息
kubectl describe svc nginx-service
使用endpoints指令,查看后端关联的后端节点
[root@master01 ~]#kubectl get endpoints -n china
NAME ENDPOINTS AGE
nginx-server 10.244.1.41:80,10.244.1.42:80,10.244.2.54:80 78m
也可以通过kubectl describe 指令查看service的描述信息
[root@master01 ~]#kubectl describe svc nginx-server -n china
Name: nginx-server #serivce名称
Namespace: china #所在命名空间
Labels: app=nginx #标签名称
Annotations: <none> #服务没有注解
Selector: app=nginx #服务的选择器,表示所有具有app=nginx标签的Pod都将作为此服务的后端
Type: NodePort #服务的类型是NodePort
IP Families: <none> #服务没有指定特定的 IP 地址族
IP: 10.96.47.51 #服务的 ClusterIP
IPs: 10.96.47.51 #同上,列出了服务的 ClusterIP
Port: <unset> 80/TCP #<unset> 表示没有为服务定义命名端口,默认的端口和协议(80/TCP)被列在了后面
TargetPort: 80/TCP #流量将被转发到 Pod 上的 80/TCP 端口
NodePort: <unset> 32444/TCP #NodePort端口号为32444
Endpoints: 10.244.1.41:80,10.244.1.42:80,10.244.2.54:80 #该服务提供服务的 Pod 的 IP 地址和端口
Session Affinity: None #没有启用会话亲和性,这意味着对于客户端的连续请求,可能会被路由到不同的 Pod
External Traffic Policy: Cluster #设置为 Cluster。路由外部流量到集群的所有Pods上
Events: <none> #显示为 <none>,表示没有与该服务相关的事件
使用客户端浏览器访问任意一个节点ip的32444端口,都可以访问到nginx的pod实例
2.3 kubectl set——更新命令
更改现有应用资源一些信息
查看帮助信息--help
kubectl set --help
2.3.1 获取修改模板
kubectl set image --help
2.3.2 讲nginx版本进行更新
kubectl run nginx05 --image=nginx:1.14 -n ky36
pod/nginx05 created
kubectl get pod -n ky36kubectl expose pod/nginx05 -n ky36 --port=80 --target-port=80 --name=nginx-service --type=NodePort
kubectl get pods,svc -owide -n ky36
curl 192.168.2.16:31317 -I
kubectl set image pod/nginx05 nginx05=nginx:1.18 -n ky36
kubectl get pods,svc -n ky36 -owide
curl 192.168.2.16:31317 -I
kubectl set是一个用于设置资源字段的命令行工具,它提供了一种直接修改 Kubernetes 资源字段的方式,而无需直接编辑 YAML 或 JSON 文件。kubectl set 命令通常用于快速修改资源的某些属性,如环境变量、标签、注解等
三、修改各pod访问界面为自定义界面,验证负载均衡
负载均衡
当上述条件以及service创建好后,会以默认轮询的方式实现负载均衡
在任意node节点上下载ipvsadm,使用ipvsadm命令查看负载均衡端口
[root@node01 ~]#yum install ipvsadm -y
[root@node01 ~]#ipvsadm -Ln
修改各pod访问界面为自定义界面,验证负载均衡
kubectl exec可以跨主机登录容器,docker exec 只能在容器所在主机上登录
kubectl exec -it <pod-name> <-n ns> bash
但是,使用curl浏览器与web浏览器访问结果不一样,需要注意
在集群内部使用curl访问集群集群service的IP地址
使用集群节点的web浏览器访问时,它会将多次请求转发到同一个pod实例上。这通常是由浏览器行为或网络配置导致的,主要原因可能在与连接复用
现代浏览器通常会复用 TCP 连接,以减少延迟和开销。这意味着,如果浏览器已经与某个 Pod 的某个端口建立了连接,并且这个连接仍然处于打开状态,那么浏览器可能会继续使用这个连接发送请求,而不是尝试与集群中的其他 Pod 建立新的连接
四、版本回滚
kubectl rollout 是一个用于管理 Kubernetes 部署(Deployments)和其他资源的滚动更新的命令。通过 kubectl rollout,你可以触发滚动更新、检查状态、撤销更新等操作
[root@master01 ~]#kubectl rollout --help
#查看回滚指令帮助说明
4.1 查看历史版本
kubectl rollout history deployment/my-deployment
用于查看资源的滚动更新历史。例如,可以查看Deployment的所有历史版本。
kubectl rollout history deployment/my-deployment --revision=num
查看特定版本的详细信息
------------------------------------------------------------------------------------
[root@master01 ~]#kubectl rollout history deployment nginx -n china
deployment.apps/nginx
REVISION CHANGE-CAUSE
1 <none>
2 <none>
------------------------------------------------------------------------------------
REVISION #显示历史中的每个版本,最多记录三次
CHANGE-CAUSE #显示触发该版本变更的原因。显示为 <none>,表示没有明确的变更原因被记录
#Kubernetes本身不会自动为每次Deployment的更新填充CHANGE-CAUSE字段。
#这个字段通常是通过设置 Deployment 的注解(annotation)来填充的
#特别是 kubernetes.io/change-cause 这个注解。
#当使用某些工具进行更新时,这些工具可能会自动设置这个注解
4.2 撤销上一次更新
kubectl rollout undo
用于撤销资源的上一个滚动更新。
例如,如果最近的Deployment更新有问题,可以使用此命令回滚到上一个版本。
----------------------------------------------------------------------------
[root@master01 ~]#curl 192.168.83.40:30941 -I
HTTP/1.1 200 OK
Server: nginx/1.20.2 #现在的版本为1.20.2
Date: Mon, 20 May 2024 04:54:42 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 16 Nov 2021 14:44:02 GMT
Connection: keep-alive
ETag: "6193c3b2-264"
Accept-Ranges: bytes
[root@master01 ~]#kubectl rollout undo deployment nginx -n china #回滚到上一次版本
deployment.apps/nginx rolled back
[root@master01 ~]#curl 192.168.83.40:30941 -I
HTTP/1.1 200 OK
Server: nginx/1.18.0 #上一次版本为1.18.0
Date: Mon, 20 May 2024 04:54:53 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 14:09:01 GMT
Connection: keep-alive
ETag: "5e9efe7d-264"
Accept-Ranges: bytes
---------------------------------------------------------------------------
也可以通过 kubectl rollout undo deployment/my-deployment --to-revision=num
指定回滚到某一个历史版本,num对应kubectl rollout history查看的revision的值
---------------------------------------------------------------------------
[root@master01 ~]#kubectl rollout status deployment nginx -n china
deployment "nginx" successfully rolled out
----------------------------------------------------------------------------
kubectl rollout status
用于检查一个资源的滚动更新状态。例如,可以用它来检查Deployment的Pods是否都已更新到新的版本自主式pod无法查看
声明式pod可以查看
4.3 执行回滚到上一个版本
kubectl rollout undo deployment/nginx-aa -n ky36
4.4 执行回滚到指定的版本
kubectl rollout undo deployment/nginx-aa --to-revision=2 -n ky36
-revision=2:指定的是上方history里面的第几个
4.5 检查回滚状态
kubectl rollout status deployment/nginx--aa -n ky36
4.6 kubectl delete 删除命令
//删除副本控制器
[root@k8s ~]# kubectl delete deployment/nginx-aa -n kube-public
deployment.apps "nginx-cc" deleted
//删除service
[root@k8s ~]# kubectl delete svc/nginx-service
service "nginx-service" deleted
[root@k8s ~]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment 1/1 Running 1 33h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.125.0.1 <none> 443/TCP 40h
五、edit修改版本
kubectl get pod -o wide
kubectl edit pod nginx-deployment-f77774fc5-sd975 -n default
进入指定的pod 的yaml 文件
删除修改的pod进行验证,如果有副本控制器会重新创建一个pod,是根据yaml文件的配置来重建的所有为1.21.5 版本
watch -n 1 kubectl get pods
当不知道yaml文件在哪时,过滤出控制器
kubectl get all -A |grep nginx-deployment
六、金丝雀发布(灰度发布)
金丝雀发布(Canary Release),也被称为灰度发布或金丝雀部署,是一种降低在生产环境中引入新软件版本风险的技术。它允许在将更改全面推广到整个基础架构之前,先将这些更改缓慢地推广到一小部分用户,以验证新版本的稳定性和可靠性。
金丝雀发布的名称来源于矿工使用金丝雀来检测矿井中是否存在有毒气体的做法。同样地,金丝雀发布允许团队在将新版本软件发布给所有用户之前,先将其发布给一小部分用户,以检测新版本是否存在问题
在Kubernetes(K8s)中,金丝雀发布(Canary Release)是一种用于在生产环境中逐步推出新版本应用程序的策略。它的主要目标是在不影响所有用户的情况下,先让一小部分用户或流量使用新版本,以便测试和验证新版本的稳定性和性能。如果新版本出现问题,可以迅速回滚到旧版本,从而避免影响整个生产环境
Deployment控制器支持自定义控制更新过程中的滚动节奏,如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布
kubectl rollout pause deployment/my-deployment
#用于暂停一个资源的滚动更新。这在你想要暂停更新过程并稍后继续时很有用
kubectl rollout resume deployment/my-deployment
#用于恢复一个之前被暂停的滚动更新。
在新的命名空间中创建pod实例并暴露端口,对外提供服务
[root@master01 ~]#kubectl create deployment nginx --image=nginx:1.18 --replicas=3 -n nginx-test
deployment.apps/nginx created
[root@master01 ~]#kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-svc --type=NodePort -n nginx-test
service/nginx-svc exposed
[root@master01 ~]#kubectl get pod -n nginx-test -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-84b9b46f96-6vz9b 1/1 Running 0 7m35s 10.244.1.74 node01 <none> <none>
nginx-84b9b46f96-7qmv4 1/1 Running 0 7m35s 10.244.2.88 node02 <none> <none>
nginx-84b9b46f96-8fkfk 1/1 Running 0 7m35s 10.244.2.87 node02 <none> <none>
[root@master01 ~]#kubectl get service nginx-svc -n nginx-test -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
nginx-svc NodePort 10.96.182.14 <none> 80:31088/TCP 2m2s app=nginx
更多推荐
所有评论(0)