kubectl陈述式资源管理

2024-08-28 21:36
文章标签 资源管理 kubectl 陈述

本文主要是介绍kubectl陈述式资源管理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

概念

kubectl的基础命令

*每天常用的查看集群的基本信息

deployment的部署方式

deployment 的特点

基于deployment创建pod

手动缩容

service的类型以及工作原理

创建service

service的类型

修改service的类型为nodeport

**nodeport实验:对外暴露端口

滚动更新以及回滚

对版本进行滚动更新

回滚

销毁


概念

kubectl 是陈述式资源管理方式(命令行)   管理就是增删改查

资源对象包含pod、控制器、service,我们创建资源对象时会用声明式,用yaml文件写的

陈述式命令的开头是 kubectl 

k8s项目的生命周期:发布——修改——更新——回滚——销毁

kubectl的基础命令

kubectl version  查看集群的版本

kubectl api-resources  查看资源对象的版本和简写

kubectl cluster-info  查看集群的信息

journalctl -u kubelet -f 和 tail -f /var/log/messages  查看集群的日志

*每天常用的查看集群的基本信息

kubectl get cs  查看集群组件的健康状态

kubectl get node  查看节点的状态

kubectl get pod  查看默认命名空间里面当前运行的pod   默认命名空间是default

了解即可:

name:pod的名称

ready:1/1 表示正常状态

status :running  表示运行   

只有1/1和running才表示pod属于正常状态

restarts 表示pod的重启次数。因为自愈功能,pod在非正常状态下,会自动进行重启,状态正常之后就不会再进行重启。    

AGE:当前pod的运行时间

kubectl create ns xy102 创建命名空间

kubectl delete ns xy102  删除命名空间

kubectl get all  查看当前命名空间的所有资源

kubectl get pod -o wide  查看pod的详细信息 (pod被部署在哪个节点上)

deployment的部署方式

资源对象的部署方式叫做deployment。它是无状态部署方式:pod的名称是随机生成的。

deployment 的特点

1.创建时可以指定副本数(pod的数量)、

2.滚动更新:先更新一个,更新好了之后再更新余下的pod

3.自我修复:默认的策略就是重启容器,删除pod相当于重启pod

4.支持回滚:如果更新有问题,可以恢复到上一个版本

5.支持pod数量的扩容和缩容(手动)

基于deployment创建pod

首先要kubectl create ns xy102 创建命名空间

kubectl create deployment test1 --image=nginx:1.22 --replicas=3 -n xy102  基于deployment创建的pod

kubectl delete pod test1-86776958-5br7q -n xy102  重启pod,不能删除

基于 deployment创建的pod, delete pod 相当于重启,不能删除pod

kubectl run nginx1 --image=nginx:1.22 -n xy102   run直接创建pod  删除这个就是真的删除

kubectl describe pod -n xy102 test1-86776958-5br7q  查看这个pod的详细情况

创建pod流程:调度策略(把pod部署到哪个节点上)——拉取镜像——创建容器——运行容器

kubectl describe deployments.apps -n xy102 test1 查看创建的资源对象的信息

kubectl logs -f test1-86776958-5br7q -n xy102 查看pod的日志

kubectl exec -it -n xy102 test1-86776958-5br7q bash   进入pod内的容器

手动缩容

方式一:命令行: kubectl scale deployment nginx1 -n xy102 --replicas=1

方式二:在yaml文件:kubectl edit deployment nginx1 -n xy102  

进入之后修改replicas即可

注:pod的ip地址随着pod的生命周期有可能会发生变化,内部访问我们通过pod的ip可以直接访问,外部访问不会受到影响。

service的类型以及工作原理

service如何与pod进行关联,这种关联不受pod的ip地址的变化影响

创建service

kubectl expose deployment nginx1 --port=80 --target-port=80 --name=nginx - n xy102

注:前一个port是集群的service的端口,是和容器内的80做的映射

kubectl get svc  查看service

service的类型

1.ClusterIP 默认类型,提供集群内部的一个虚拟ip地址。是用来让其他的pod来访问的,pod可以通过这个service的ip地址直接访问到内部的容器。只能内部访问,外部不能访问。是内部组件通信使用。(对内)

2. NodePort:在每个节点(集群的所有节点)都会开放一个端口,外部就可以通过本机的ip+端口(nodeport端口)访问pod内的容器服务。每个节点nodeport的端口都是一致的,端口是有范围的:30000-32767  (对外)

修改service的类型为nodeport

kubectl edit svc -n xy102 nginx1

此时80是service端口   31151是所有节点上开放的端口(所有的节点主机本机ip都能访问)

访问的流程:在宿主机上开放的端口31151——service的80端口——pod里面容器的80端口

**nodeport实验:对外暴露端口

流程图:

deployment的标签是app=nginx1

由于service匹配的标签是app=nginx1,只要资源对象的标签包含app=nginx1,所以都可以通过service进行转发

kubectl edit pod nginx2 -n xy102 进入yaml文件

把labels指向app=nginx1

实验结果:

此时访问本机的31151端口 就能访问到所有的pod

总结:nodeport:service根据标签来匹配对应的pod,只要标签匹配,都能转发打到指定的pod内的容器。

3.LoadBalancer:云平台的运营商(阿里云、腾讯云)提供loadbalancer的地址     地址需要付费

提供之后也是通过访问负载均衡的地址,来实现pod的流量转发

4.ExternalName:把service的名称映射到DNS的域名上。就是让pod去访问集群外部的资源,而且设置为此类型service将不能提供四层负载均衡服务。

滚动更新以及回滚

对版本进行滚动更新

kubectl set image deployment/nginx1 nginx=nginx:1.18 -n xy102

此时 kubectl get pod -o wide -n xy102 即可查看是否正则更新

kubectl rollout history deployment/nginx1 -n xy102  查看还原点

数字大小决定了距离上次更新操作的远近,数字越大,就是最近的一次操作

kubectl set image deployment/nginx1 nginx=nginx:1.20 --record -n xy102       record添加更新记录

回滚

kubectl rollout undo  deployment/nginx1 --to-revision=5 -n xy102 回滚

销毁

所以基于deployment创建的资源对象的pod如果要删除,首先要先删除deployment,然后再删除service,最后再删除命名空间。

这篇关于kubectl陈述式资源管理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1115943

相关文章

【Python知识宝库】上下文管理器与with语句:资源管理的优雅方式

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 文章目录 前言一、什么是上下文管理器?二、上下文管理器的实现三、使用内置上下文管理器四、使用`contextlib`模块五、总结 前言 在Python编程中,资源管理是一个重要的主题,尤其是在处理文件、网络连接和数据库

理解C++全局对象析构顺序与 IPC 资源管理:避免 coredump

文章目录 0. 概述1. 问题背景2. 问题分析3. 解决方案:手动释放资源4. 深入剖析:为什么手动调用 `reset()` 有效?5. 延伸思考:如何避免全局对象带来的问题?6. 总结 0. 概述 在编写 C++ 程序时,使用全局或静态对象有时可能会导致不可预期的崩溃(如 coredump)。这类崩溃通常源于对象的析构顺序、资源的管理方式,以及底层资源(如 IPC 通道或共

业务资源管理模式语言09

示例: 图13 表示了QuoteTheMaintenance 模式的一个实例,在汽车修理店系统中,其中“Vehicle”扮演“Resource”,“Repair Quotation”扮演“Maintenance Quotation”,“Repair shop branch”扮演“Source-party”,“Customer”扮演“Destiny-Party”。 图13——QuoteThe

Winsock服务器内存资源管理

一般来讲, 在服务器上,如果有足够的资源,Winsock server,理论上可以支持成千的并发连接。而现实是,我们没有足够的资源可供使用,分配。本文主要来讨论一下内存资源之于Winsock server开发的重要性。 一)基本概念。 -> Pages,Locked Pages.         在现代操作系统中,内存管理会把主存(RAM)分成Pages来管理。 Paging(或者swap

Unity 热更 之 【YooAsset 热更】Unity 可以进行热更的资源管理系统,并 【Android 端简单实现·案例热更】

Unity 热更 之 【YooAsset 热更】Unity 可以进行热更的资源管理系统,并 【Android 端简单实现·案例热更】 目录 Unity 热更 之 【YooAsset 热更】Unity 可以进行热更的资源管理系统,并 【Android 端简单实现·案例热更】 一、简单介绍 二、YooAsset  引入工程 三、Sample 案例 Android 端 热更 四、Python

Linux IPC 资源管理:ipcs和 ipcrm使用指南

文章目录 0. 引言1. IPC 资源概述2. 查询 IPC 资源2.1 使用 `ipcs` 查询 IPC 资源2.2 查询特定 IPC 资源2.3 查询系统 IPC 参数 3. 修改 IPC 系统参数4. 清除 IPC 资源5. 实践应用5.1 查询用户的消息队列5.2 查找未被清理的消息队列 0. 引言 进程间通信(IPC)允许不同的进程共享数据或进行同步操作。Linux

Kubectl:Kubernetes 的强大命令行工具

前言 在 Kubernetes 这一强大的容器编排平台中,kubectl 无疑是一把至关重要的利器。它就像是一位全能的指挥官,让用户能够与 Kubernetes 集群进行高效而直接的交互。无论是管理容器化应用的部署、监控资源的使用情况,还是处理故障排查等任务,kubectl 都发挥着不可或缺的作用。 Kubernetes 以其高度的可扩展性和灵活性,成为了现代云原生应用开发和部署的首选平台。而

《深入理解 C++中的 RAII:资源管理的利器》

在 C++编程中,资源管理一直是一个至关重要的问题。良好的资源管理可以提高程序的稳定性、可靠性和性能。而 C++中的 RAII(Resource Acquisition Is Initialization,资源获取即初始化)技术正是解决资源管理问题的一把利器。那么,RAII 究竟是什么?又该如何实现呢?让我们一起来深入探讨。 一、RAII 的概念 RAII 是一种在 C++中管理资源的编程技术

基于RFID光触发标签的光交箱哑资源管理方案

光交箱作为通信网络的关键节点,其哑资源的有效管理对于保障通信服务的质量和稳定性至关重要。然而,传统的管理方式在面对日益庞大和复杂的光交箱哑资源时,逐渐暴露出诸多问题,如资源信息不准确、故障定位困难、管理效率低下等,在此背景下,结合物联网技术手段,探索创新的管理方案成为当务之急。 一、光交箱哑资源管理的难点与痛点 (一)资源信息不准确 由于光交箱哑资源数量庞大、分布广泛,且大多为无源设备,传统