k8s架构原理

一、k8s架构图

二、k8s架构模式:
master(cluster)/worker(node)架构

master组件:
1.kube-apiserver:

提供restful接口指令供客户端或者其他组件调用，客户端指的是kubectl命令行工具，其他通信组件包括controller和scheduler

2.etcd:

负责存储集群状态

3.controller

管理并实现k8s的的各种流程,使用k8s管理容器，而不是直接使用容器，目的就是为容器提供统一编排，为用户提供声明式的调用，k8s维护着用户的期望,用户只要告诉k8s需要几个服务，需要什么配置就可以了，不需要关心底层k8s怎么实现的,但是k8s除了正常的创建管理，还伴随着异常情况的发生，比如容器挂掉,网络不通等，这时候需要controller监控资源状态等信息并更新到etcd，controller相当于运维工程师的角色.
k8s把各种操作都认为是某种类型的某个方法,从而将不同的操作分给不同的方法执行,k8s认为一切皆资源,繁复的内容抽象成不同的资源放到不同的方法上执行

4.Scheduler

资源调度，根据系统资源的使用情况，将pod合理分配到相应的node节点,并通过apiserve告知etcd更新数据库

worker组件:
1.kubelet

controller如何监控不通资源信息，Scheduler如何给pod分配资源，实际的操作都是交给kubelet来完成的，例如，创建pod，删除pod，创建数据卷等

2.kube-proxy

按照用户的期望创建好环境，pod容器怎么才能对外提供服务?
    pod生成是会自动分配一个ip,但这个ip是动态生成的，并不固定，这时就需要一个固定ip代理pod来对外提供服务，这个就是service资源,扮演者服务发现和负载均衡的功能。
但是service怎么代理到pod上呢?
这时就需要core-dns,为新创建的pod注册动态DNS。给pod的service添加iptables/ipvs规则，用于服务发现和负载均衡，所有网络相关的请求响应都有kube-proxy代理完成

3.container runtime

负责容器运行

三、工作流程

1.创建pod

• apiserver接收到用户创建pod的请求，会根据用户提交的参数值创建pod对象,apiserver检测用户提交的参数，参数不合规则创建失败
• pod对象创建成功后，etcd会持久化这个对象,测试pod处于pending状态
• Scheduler会通过list-watch机制 调用apiserver监听etcd数据变化,如果发现有个pod未bind到node上，就会读取etcd存储的pod信息,根据策略算法，将pod调度到相应的node上
• 此时各node也会通过kubectl调用apiserver接口监听etcd对象状态变化，被分配到的node发现当前的node状态，和用户期望的状态有个pod不一致，他就会创建pod(包括挂载数据卷，创建pause容器接管应用容器网络),创建成功后，会将信息通过apiserver更新到etcd中.

2.controller创建pod
第1步成功之后，需要controller接手监控工作
用户期望pod副本数是3，但此时宕掉一个pod, controller loop 监测到 etcd 中存储的对象状态有些与系统 current state 不一致(此例例⼦子中就 是那个宕掉的容器器导致的), replicationController, replicaSet, deployment 等等定义必须有 3 个容器, 然⽽目前系统只有 2 个 running, 然后通过对应的⽤用户定义时存储在 etcd 的对象类 型, 相应的controller 会去响应, 发现少了了 1 个容器器, 需要创建 1 个新容器器时, 由该 controller 请求 api server 创建新容器,接下来跟第一步相同

总结:

1. etcd 仅能通过 api server 访问
2. etcd 中通过 api server 来保证存储数据是结构化的
3. controller, scheduler, kubelet, kube-proxy 这些组件都是实质上都是通过 watch etcd 中存储的对象状态来进⾏行行对应⼯工作的, 但是必须通过 api server; 他们之间是没有调度的 上下级关系的, ⽽而是通过 etcd 对象状态的变化来触发对应的 event 处理理
4. k8s 内部⼯工作的机制实质是维持⽤用户提交的期望 (存储在 etcd) 与系统当前状态⼀一致
5. k8s 中有个 control loop ⼀一直循环监控着系统状态