kubernetes简介

k8s是一个便携的,可扩展的,以及开源的平台,用来管理容器化的工作负载和服务,该基础设施兼具声明式配置和自动化特性。k8s是一个大型的,快速成长的生态系统。使用k8s服务,支持以及工具,具备广泛的可行性

关键词:容器编排

由于篇幅限制,由来就不做介绍。

详细文档:https://k8s.amrom.tk/

架构详解

架构图

控制平面:kube-controller-manager kube-apiserver kube-scheduler

工作平面:kubelet kube-proxy

数据存储:etcd

通信机制

Kubernetes具有“中心辐射型” API模式。 来自节点(或它们运行的Pod)的所有API使用都在apiserver处终止。 其他控制平面组件均未设计为公开远程服务。 apiserver配置为侦听启用了一种或多种形式的客户端身份验证的安全HTTPS端口(通常为443)上的远程连接。 应该启用一种或多种形式的授权,尤其是在允许匿名请求或服务帐户令牌的情况下。

控制平面与工作平面的通信默认为使用HTTP连接,具体为kubeletkube-apiserver的实时通信。通信的主要目的有如下:

  • 正在获取pod的日志。
  • 附加到运行中的pod
  • 提供kubelet的端口转发功能。

![image-20210902134222837](/Users/apple/Library/Application Support/typora-user-images/image-20210902134222837.png)

机制原理

kubernetes对工作负载进行了封装,以Deployment和statefulset形式分发,一个完整的部署流程可以看作如下:

  1. 控制平面,输入声明式文件,该文件由kubectl提交到apiserver解析,然后存储到etcd,该文件以kind: 标示自身的资源类型。
  2. kube-controller-manager根据资源类型,选择适当的控制器解析文件,匹配标签、选择器、存储卷,以及其他过滤器
  3. kube-scheduler根据该资源的自身要求,以及工作节点当前的状态,决定将任务下发到哪一个工作节点。
  4. kube-apiserver进行任务的下发
  5. kubelet 工作于工作节点,接受到任务后,在自身节点调用具体的runtime启动容器
  6. kubelet会定期上报自身节点信息,以及运行在自身节点的容器状态,上报到apiserver

kubernetes的机制可以理解为一个标准的list/watch机制,其控制平面与工作平面各司其职,通过HTTP通信上报/下发数据。

其资源的解析,部分发生在控制平面,部分发生在工作平面。

可以考虑的扩展

  1. 离线场景的处理

    通过在工作节点外挂数据库,存储当前节点的数据,来实现控制平面与工作节点断连时的正常运行。

  2. 非容器类型的编排

    通过自定义资源类型,以及自定义控制器,来实现非容器类型的任务下发,工作节点需要实现与之对应的运行时程序。

kubeedge的实现

介绍

KubeEdge是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于kubernetes构建,并为网络应用程序提供基础架构支持。云和边缘之间的部署和元数据同步。 KubeEdge使用Apache 2.0许可。并且绝对可以免费用于个人或商业用途。我们欢迎贡献者!

我们的目标是创建一个开放平台,使能边缘计算,将容器化应用编排功能扩展到边缘的节点和设备,后者基于kubernetes构建,并为云和边缘之间的网络,应用部署和元数据同步提供基础架构支持。

以上是官方给的介绍,理解起来就2个核心概念:

  1. 容器编排
  2. 边缘计算

架构

img

改进一 离线场景的处理

其分为控制平面和工作节点,控制平面服务容器的调度,集群配置的存储,以及针对各个工作节点的实时控制。工作节点则实时通过http通信接收控制平面下发的指令和数据,并且上报自生节点的容器状态。控制平面与工作节点以近乎实时的紧密通信,来保障集群的稳定运行。但是存在一个潜在的问题:如果控制平面和工作节点的通信断了怎么处理,工作节点的容器还能正常工作吗?新的容器任务能够下发吗?这个是k8s自身的一个缺陷,即离线场景的处理。kubeedge实现了离线场景下的调度。kubeedge在设计上直接考虑了离线的清醒,其分为云端边缘端。很明显云端拥有整个集群的所有信息,但是边缘端也存储了一部分配置信息,由于边缘端存储了容器运行所需要的信息,所以即使处在离线场景,也能正常运行(一段时间)。

改进二 定制的组件

kubeedge定制实现了几个组件,首先是云端的cloud-controller,用来解析自定义资源类型Device;其次是edged,其代替kubelet工作在工作节点,实现 Pod,Volume,Node 等 Kubernetes 资源对象的生命周期管理,将控制平面的部分工作承接过来;metamanager负责本地元数据的持久化。

我们的定制化需求

管理以下场景:

  1. IOT设备
  2. 执行代理、网关等资源的管理
  3. 对接底座系统