Kubernetes基本概念和术语（2）_kubernetes expectation

最新推荐文章于 2024-11-01 15:32:36 发布

m0_57889860

最新推荐文章于 2024-11-01 15:32:36 发布

阅读量428

点赞数 5

分类专栏： 2024年程序员学习文章标签：运维 linux 面试

本文链接：https://blog.csdn.net/m0_57889860/article/details/138900830

版权

2024年程序员学习专栏收录该内容

259 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

扩展 Deployment 以应对高负载。
查看 Deployment 的状态，以此作为发布是否成功的指标。
清理不再需要的旧版本 ReplicaSets

1.7 Horizontal Pod Autoscaler

Horizontal Pod Autoscaling (Pod 横向自动扩容，简称HPA ）。

HPA可以有以下两种方式作为 Pod 负载的度量指标。

CPUUtilizationPercentage
应用程序自定义的度量指标，比如服务在每秒内的相应的请求数 CTPS或QPS ）。

如果某一时刻 CPUUtilizationPercentag 的值超过 80% ，则意味着当前的 Pod 副本数很可能不足以支撑接下来更多的请求，需要进行动态扩容，而当请求高峰时段过去后， Pod的CPU 利用率又会降下来，此时对应的 Pod 副本数应该自动减少到一个合理的水平。

下面展示一个YAML：

apiVersion : autoscaling/vl 
kind: HorizontalPodAutoscaler 
metadata : 
name : php-apache 
namespace: default 
spec: 
maxReplicas : 10 
minReplicas : 1 
scaleTargetRef: 
kind : Deplo nent
name : php-apache 
targetCPUUtilizationPercentage : 90

上面的HPA控制的目标对象 php-apache的Deployment里的 Pod副本，当这些 Pod 副本 CPUUtilizationPercentage的值超过90%会触发自动动态扩容行为，扩容或缩容时必须满足的一个约束条件是Pod 的副本数介于1与10之间。

1.8 StatefulSet

StatefulSet从本质上来说，可以看作 Deployment/RC的一个特殊变种，它有如下一些特性：

StatefulSet 里的每个 Pod 都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。
假设StatefulSet 名字叫kafka, 那么第1个 Pod kafka-0 ，第2个叫 kafk-1，以此类推。
StatefulSet 控制的 Pod副本的启停顺序是受控的，操作第n个Pod 时，前 n-1 Pod已经是运行且准备好的状态。
StatefulSet 里的Pod采用稳定的持久化存储卷，通过 PV/PVC 来实现，删除 Pod 时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）

StatefulSet在Headless Service 的基础上又为StatefulSet 控制的每个 Pod 实例创建了 DNS 域名，这个域名的格式为：

$(podname).$(headless service name)

比如一个三节点的Kafka StatefulSet 集群，对应的 Headless Service 的名字为 kafka,StatefulSet 的名字为 kafka，则 StatefulSet 里面的 Pod DNS 名称分别为 kafka-0.kafka,kafka-1.kafka kafka-3 .kafka ，这些 DNS 名称可以直接在集群的配置文件中固定下来。

1.9 Service(服务)

概述:

Service 也是 Kubemetes 里的最核心的资源对象之 Kubernetes 里的每个 Service 其实就是我们经常提起的微服务架构中的一个“微服务”.

Pod , RC Service 的关系:
在这里插入图片描述
通过分析、识别并建模系统中的所有服务为微服务一Kubernetes Service 最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过 TCP/IP 进行通信，从而形成了我们强大而又灵活的弹性网格，拥有了强大的分布式能力、弹性扩展能力、容错能力.

Service不是共用一个负载均衡器的地址，而是每个 Service 分配了一个全局唯一的虚拟 IP 地址，这个虚拟IP被称为 Cluster 。这样一来，每个服务就变成了具备唯一地址的“通信节点”，服务调用就变成了最基础 TCP 网络通信问题.

Kubernetes 的服务发现机制

如何通过 Service 的名字找到对应的 Cluster IP?
最早时 Kubemetes 采用了 Linux 环境变量的方式解决这个问题，即每个 Service 生成些对应的 Linux 环境变量 CENV ），并在每个 Pod 的容器在启动时，自动注入这些环境变量，以下是tomcat-service 产生的环境变量条目：

TOMCAT SERVICE SERVICE HOST=69.169.41.218 
TOMCAT SERVICE SERVICE PORT SERVICE PORT=8080 
TOMCAT SERVICE SERVICE PORT SHUTDOWN PORT=BOOS 
TOMCAT SERVICE SERVICE PORT=8080 
TOMCAT SERVICE PORT 8005 TCP PORT=BOOS 
TOMCAT SERVICE PORT=tcp://169.169.41.218:8080 
TOMCAT SERVICE PORT 8080 TCP ADDR=l69.169.41.218 
TOMCAT_SERVICE_PORT_8080_TCP=tcp://169.169.41.218:8080 
TOMCAT SERVICE PORT 8080 TCP PROTO=tcp 
TOMCAT SERVICE PORT 8080 TCP PORT=8080 
TOMCAT_SERVICE_PORT_8005 TCP=tcp://169.169.41 18:8005
TOMCAT SERVICE PORT 8005 TCP ADDR=169.169.41.218 
TOMCAT SERVICE PORT 8005 TCP PROTO=tcp

上述环境变量中，比较重要的是前3条环境变量，我们可以看到，每个 Service 的 IP地址及端口都是有标准的命名规范的，遵循这个命名规范，就可以通过代码访问系统环境变量的方式得到所需的信息，实现服务调用。

外部系统访问 Service 的问题

为了更加深入地理解和掌握 Kubemetes ，我们需要弄明白 Kubemetes 里的"三种IP"这个关键问题，这三种IP分别如下。

Node IP: Node 节点的 IP 地址
Node IP Kubemetes 集群中每个节点的物理网卡的 IP 地址.
Pod IP: Pod IP 地址
Pod IP 是每个 Pod IP 地址，它是 Docker Engine 根据 docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络，前面我们说过, Kubemetes 要求位于不同 Node 上的Pod 能够彼此直接通信，所以 Kubemetes 里一 Pod 里的容器访问另外一 Pod 里的容器，就是通过 Pod 在的虚拟二层网络进行通信的，而真实的 TCP/IP 则是通过Node 在的物理网卡流出的.
Cluster IP: Service 的IP地址
Cluster IP仅仅作用 Kubemetes Service 这个对象，并由 Kubemetes 管理和分配 IP地址（来源于 Cluster 地址池);
Cluster 无法被 Ping 因为没有一个“实体网络对象”来响应;
Cluster 只能结合 Service Port 组成个具体的通信端口，单独的Cluster 具备TCP/IP的基础，并且它们属于 Kubemetes 集群这样一个封闭的空间，集群之外的节点如果要访问这个通信端口，则需要做一些额外的工作;
在Kubemetes 集群之内， Node 网、 Pod IP 网与 Cluster 网之间的通采用的是Kubemetes 自己设计的一种编程方式的特殊的路由规则，与我们所熟知的路由有很大的不同。

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。