本文介绍: 通过域名来访问后端pod资源。LoadBalancer:如果service的类型设定为LoadBalancer,映射地址(云平台提供LoadBalancer的地址)这种用法仅用于。滚动更新,他不是一次性的把所有pod部署完毕,他是一个一个的部署更新,pod的更新时候用,逐步的引入新的pod,逐步的减少旧的pod。后台运行创建,在每个节点上都创建一个相同方式的,相同版本的容器运行的pod。查看 部署 查看pod的情况(详细的信息,日志,发布和回滚)创建—-发布—-更新—-回滚—-删除。

命令行:kubectl命令行工具

优点:90%以上的场景都可以满足

对资源的增,删,查比较方便,对改不是很友好

缺点:

命令比较冗长,复杂,难记

声明式:

K8S当中的yaml文件来实现资源管理—声明式

GUI:图形化工具的管理

1、kubectl命令

查看 部署 查看pod的情况(详细的信息,日志,发布和回滚)

[root@master01 ~]# kubectl version 
查看k8s版本

[root@master01 ~]# kubectl api-resources 
查看所有api资源对象的名称

[root@master01 ~]# kubectl cluster-info 
查看K8S的集群信息

[root@master01 ~]# kubectl get cs
查看master节点的状态

[root@master01 ~]# kubectl get pod
[root@master01 ~]# kubectl get pod -n kube-system 

查看默认命名空间内的pod的信息,加-n+命名空间的名称是查看指定命名空间的pod

[root@master01 ~]# kubectl get ns
查看当前集群所有的命名空间

[root@master01 ~]# kubectl get pod -o wide 
[root@master01 ~]# kubectl get pod -o wide -n kube-system
查看默认命名空间内,pod的详细信息,-n+命名空间,查看指定命名空间内pod详细信息

[root@master01 ~]# kubectl get node 
查询节点的信息以及状态

[root@master01 ~]# kubectl get node -o wide   查看node节点的详细信息包括真实IP以及他所使用的系统版本等
NAME       STATUS   ROLES                  AGE   VERSION    INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
master01   Ready    control-plane,master   21h   v1.20.15   192.168.211.10   <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   docker://24.0.7
node01     Ready    <none>                 21h   v1.20.15   192.168.211.20   <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   docker://24.0.7
node02     Ready    <none>                 21h   v1.20.15   192.168.211.30   <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   docker://24.0.7


[root@master01 ~]# kubectl describe pod nginx-6799fc88d8-9427k 
查看指定pod的详细信息  后面加上pod名称

[root@master01 ~]# kubectl describe pod -n kube-system kube-flannel-ds-nw9nj 
查看指定命名空间,指定pod的详细信息

[root@master01 ~]# kubectl logs -f nginx-6799fc88d8-9427k 
动态查看指定pod的日志

[root@master01 ~]# kubectl logs -f -n kube-system kube-flannel-ds-ds7r4 
查询指定命名空间内的pod日志,一定要用-n来指定 


[root@master01 ~]# kubectl create ns czy   创建命名空间
namespace/czy created
[root@master01 ~]# kubectl get ns
NAME              STATUS   AGE
czy               Active   5s
default           Active   21h
kube-node-lease   Active   21h
kube-public       Active   21h
kube-system       Active   21h
[root@master01 ~]# kubectl delete ns czy  删除命名空间 
namespace "czy" deleted
[root@master01 ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   21h
kube-node-lease   Active   21h
kube-public       Active   21h
kube-system       Active   21h



[root@master01 ~]# kubectl delete pod nginx-6799fc88d8-9427k 
删除指定pod   *要先声明动作  delete   create  get  describe 然后跟上对象: ns  pod  service  再跟上对象名称  nginx-6799fc88d8-9427k  
如果不是默认的命名空间,需要加上-n 来指定 

deployment的部署pod:

特点:有两种方式部署

1、陈述式部署:命令行

2、声明式:yaml文件进行部署

滚动更新,他不是一次性的把所有pod部署完毕,他是一个一个的部署更新,pod的更新时候用,逐步的引入新的pod,逐步的减少旧的pod

自我修复:如果有pod节点发生故障,deployment会自动启动新的pod来进行代替

回滚:如果更新有问题,deployment会提供还原点,可以手动还原到未更新前的状态。

扩容和缩容 :deploment可以随时跳转pod的数量,以适应流量的变化。

上述的功能必须是基于deploment创建的服务才可以。绝大多数的pod都是使用deployment来创建的

[root@master01 ~]# kubectl get deployments.apps 
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           21h
查看命名空间内的deployments
[root@master01 ~]# kubectl get deployments.apps -n kube-system 
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           21h
-n 查询指定命名空间 

daemonset:不能通过命令行创建,只能在yaml文件当中定义这种创建方式

后台运行创建,在每个节点上都创建一个相同方式的,相同版本的容器运行的pod

一般都是依赖坏境和重要组件,一般也不会对这些资源进行操作

[root@master01 ~]# kubectl create deployment nginx-czy --image=nginx  
用deployment 创建pod  

[root@master01 ~]# kubectl create deployment nginx-xx --image=nginx --replicas=3 -n czy
deployment.apps/nginx-xx created
--replicas=3指定副本数量 czy:指定命名空间 
[root@master01 ~]# kubectl get pod -n czy 
NAME                        READY   STATUS    RESTARTS   AGE
nginx-xx-55f6c96849-8xqcf   1/1     Running   0          91s
nginx-xx-55f6c96849-mfb87   1/1     Running   0          91s
nginx-xx-55f6c96849-zsjtz   1/1     Running   0          91s

如果是基于deployment方式创建的pod,或者是daemonset方式创建的pod是由控制器创建的pod
使用delete删除pod是删不掉的,如果你使用delete,相当于重启 

[root@master01 ~]# kubectl delete deployments.apps -n czy nginx-xx 
deployment.apps "nginx-xx" deleted
删除deployment
基于deployment方式创建pod,一旦删除deployment,基于这个deployment创建的pod都会被删除 
不是基于控制器创建的,会被直接删除 

kubectl delete pod nginx-czudajdpu301983 –force –grace-period=0

grace-period:表示过度活期,默认是30秒

主要是用于结束卡在销毁状态的pod

对deployment创建的pod进行缩容

[root@master01 ~]# kubectl scale deployment nginx-czy --replicas=3 
deployment.apps/nginx-czy scaled
扩容
[root@master01 ~]# kubectl scale deployment nginx-czy --replicas=1
deployment.apps/nginx-czy scaled
缩容
只适用于deployment
service的类型:
ClusterIP:创建service时的默认类型,提供一个集群内部的虚拟IP地址,这是service的默认类型。通过虚拟IP可以直接访问pod的资源,但是仅限于内部请求,无法对外提供访问。
NotePort:会在每个node节点上都开放一个相同的端口。外部可以通过node的本机IP+端口,访问pod资源。集群外部访问service的一种方式。四层代理方式
nodeip:nodeport
随机指派,也可以指定 从30000开始到32767 
基于deployment创建的pod,可以使用的方式

--port=80 service集群端口 
--target-port=80 pod内部容器的端口 



[root@master01 ~]# kubectl expose deployment nginx1 --port=80 --target-port=80 --name=nginx-service --type=NodePort 
service/nginx-service exposed
[root@master01 ~]# kubectl get svc
NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1      <none>        443/TCP        23h
nginx-service   NodePort    10.96.165.42   <none>        80:30512/TCP   6s
创建service

10.96.165.42 集群内部的IP地址 外部不可以访问这个ip地址

80:对应的是内部的service的端口

30512:和内部的service的80端口做映射

pod内部的容器的端口是固定的

–port是service和容器映射的端口,可以是任意只要没被占用

LoadBalancer:如果service的类型设定为LoadBalancer,映射地址(云平台提供LoadBalancer的地址)这种用法仅用于

公有云服务供应商在云平台设置的service的场景。外部来访问实现负载均衡。

创建好了servicw,指定类型为LoadBalancer,会给你提供一个地址来代理pod内部的ip地址

ExternalName:DNS映射,给service分配一个域名。通过域名来访问后端pod资源。ExternalName的service类型,不能提供负载均衡

必须要设置一个LoadBalancer的地址才可以实现

更新和回滚以及发布的方式:

项目的声明周期:

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

[root@master01 ~]# kubectl set image deployment nginx2 nginx=nginx:1.10 
deployment.apps/nginx2 image updated
修改服务版本

回滚

[root@master01 ~]# kubectl rollout history deployment nginx2 
deployment.apps/nginx2 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
数字的大小决定了距离上次操作的远近,数字越大,就是你最近的一次操作 

[root@master01 ~]# kubectl set image deployment nginx2 nginx=nginx:1.15 --record 
加上--record会打上标识 不会显示none值


[root@master01 ~]# kubectl rollout undo deployment nginx2 --to-revision=1
deployment.apps/nginx2 rolled back
回滚到1这个点 

原文地址:https://blog.csdn.net/2301_78496557/article/details/135403983

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如若转载,请注明出处:http://www.7code.cn/show_53946.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注