初步认识 kubernetes

最新推荐文章于 2024-11-08 12:15:52 发布

呈大侠

最新推荐文章于 2024-11-08 12:15:52 发布

阅读量208

点赞数

分类专栏： DevOps 文章标签： kubernetes devops

本文链接：https://blog.csdn.net/weixin_39869513/article/details/105243322

版权

DevOps 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

kubernetes集群描述

master 节点：安装kubernetes核心组件的主机
node 节点：work 工作节点，每个工作节点上运行一个 kubelet 服务，<kubelet相当于 Mesos Slave 节点>，也就是当前节点的运行时总管，会管理当前节点运行的所有服务。
pod：运行在 node 节点上面，是 k8s 最小单元，而所有的容器都运行在 pod 里面，一个 pod
service ：是包在 pod 上面的一个逻辑存在的集合，有自己的 IP <对外提供服务>，可以包含多个 pod 使用同一个 IP <主要用途：实现负载均衡，滚动更新>；
service 定义：使用 Label Selector 当定义一个 Service 的时候，可以给它指点一个标签，比如 app=b 这个标签的 pod 都属于同一个 Service。
deployment 部署描述：master 节点上发起 deployment ，这个叫部署，比如关停某个 node 节点上的服务 <部署 pod 或 Service>。
部署 Service 案例：从 master 节点上发起 deployment 想给某个 Service 扩容，实际扩容对象是 pod ，应为 Service 只是通过 Label Selector 将一组 pod 划分为一个逻辑组，它只是逻辑存在的一个东西，为了实现负载均衡而已
滚动更新：启动新的 pod，这个时候旧的 pod 和新的同时存在，再关闭旧的 pod 实现不停服务发版 <在更新过程中 Service 的 IP 是保持不变>。

Kubernetes 整体架构

Master 虚线部分代表 API Service 提供资源操作的唯一入口。并且提供授权和 Kubernetes 的访问控制。
可通过 Kubectl 或自己开发的客户端通过 Http 请求去访问 API Service 从而实现对整个集群的控制
ControllerManager 负责对整个集群的状态，比如故障检测、扩缩容、滚动更新。等等
Schedule 负责资源调度，按照预定的调度策略，把 pod 调度到相应的 Node 节点上。
ETCD 负责集群的存储，存储 pod、Service，集群的状态等等一些信息，就是 K8S 集权需要持久化的数据。
Kube-dns 负责整个集群的 DNS 服务，这个组件不一定要有，如果不通过名字去访问的话，可以不用kube-dns，建议通过名字访问使用buke-dns。
Dashboard 提供整个集群的一些数据展示和一个 UI 界面
Node 节点上都有一个 kubelet 负责维护容器在当前节点的生命周期、网络和管理。

描述一个 pod 的 deployment <部署> 全过程

首先用户执行 Kubectl 向 API Service 发起一个命令，然后请求经过认证之后。经过Schedule 的各种策略评分计算去得到一个目标的 Node<机器>。
然后告诉 API Service，API Service 就会请求相应 Node 的 Kubelet，Kubelet 就会把相关的 pod 运行起来，接着 API Service 还会将这个 pod 的信息存储到 ETCD。
最后 pod 运行起来之后，ControllerManager 开始管理这个 pod 的状态，比如：pod 挂了，它可能会再重启一个，还有就是扩缩容。
pod 是有独立的 IP 的，在集群中可以通过 IP 访问，但是这个 IP 可能会变，比如挂了，重启就变了，所以最好是外面包一层 Service。具体完成 Service 工作的是 Kube-proxy。
如果要在集群外访问集群内的服务的话，Kube-proxy 可以直接将服务端口暴露在当前 Node 的机器上，然后外面的机器可以直接访问 Node 的端口。
Kubernetes 可以通过名字来访问集群内的机器，这就是通过 Kube-dns 来实现的，它提供了整个集群的 DNS 服务，让每个 pod 都可以通过名字来相互访问。

Kubernetes Schedule <调用策略>

preselect 预选规则：

NodiskConfilct:看看有没有挂载的冲突，如果一个 pod 需要一个挂载，然后在这台机器上的挂载被其它 pod 占用，这就是挂载冲突，它不会让挂载冲突。
CheckNodeMemoryPressure：检查当前节点的内存压力，只有内存压力为零节点才可以调度，它还有对磁盘压力的检查，磁盘是不是不太够。
NodeSelector：节点选择器，可以选择指定的 host name 或者具有指定标签的节点。
FitResource：Node 要满足 pod 的 CPU，GPU等资源的要去。
Affinity：一个 pod 要和另一个 pod 运行在一起，或一个 pod 最好要和另一个 pod 运行在一起，还有亲和性和反亲和性，一个 pod 最好不要和另一个 pod 运行在一起。

optimize-select y优选规则

通过 preselect 预选规则选出来一些后，对这些 Node 进行打分，Kubernetes 会通过优先级函数去处理每一个待选的 Node，每一个优先级函数会返回
一个 0-10 分数，分数越高，表明这台 Node 越好，同时每一个函数也会对应一个权重，最终选择分值最高的 Node 来部署。

SelectorSpreadPriority：

对于同一个 Service 或者 pod 尽量会分布在不同的机器上，如果指定了区域，则会尽量分布在不同区域的机器上。

LeastRequestPrioity:

节点 pod 的总容量减掉新的 pod 节点，然后再除以总容量，就是当这 pod 运行在这个节点之后这个节点还有多少空闲，空闲越高，分数越大。

Kubernetes pod 的通信

pod 的内部通信：同一个 pod 的两个容器可以直接用 localhost 访问。
同一个 Node 节点不同 pod 的通信：同一个 Node 的 pod 都关联在同一个网桥 docker0 上，可以直接通过 pod 的 IP 进行访问。
不同 Node 不同 pod 进行访问：要满足条件，pod 的 IP 不能相同，pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让 pod 可以相互访问。

Kubernetes 服务发现

Kube-proxy(ClusterIP):对于每个服务安装一个<IP映射规则插件>,会给所有相关的 pod 做一个虚拟 IP <IP是固定的，只要Service不删除>,然后将虚拟IP的流量重定向到pod的逻辑集合。
Kube-proxy(NodePort):在每个Node上都起一个监听端口，相当于把服务暴露在节点上，这样就可以让集群外的机器通过Node IP和port访问到集群内的服务。
Kube-dns：负责集群内部的dns解析，目的是让pod之间通过名字访问。

参考：https://github.com/liuyi01/kubernetes-starter