Published on

K8s学习手记-1

Authors
  • avatar
    Name
    wellsleep (Liu Zheng)
    Twitter

最近接触了许多新技术,数据库方面的 ELK,计算架构方面的 K8s,概念方面的云原生,以及运维方面的 DevOps 等等。感觉即便是视角片面,理解存在偏差,也应该记一下,避免以后由于忙于其他方面,抽空学的一点点技术也没记住,荒废了本行(虽然也算不上是本行...)。

接触 K8s (Kubenetes) 是因为 Coding.net 的持续集成除了 堡垒机+主机组 的方式,基本只有 K8s 一条选择。为此不得不花了不少小时数去学习 K8s 到底是什么东西,它的优势在哪,坑集中在哪里。以目前十小时以内的学习和实践经验感觉,K8s 是个很强大的东西,架构搭建完成、应用熟练后,会感觉整个云计算的算力尽在把握。不过越强大的东西入门门槛越高,由于高层封装不够成熟,一旦要接触 K8s 就不得不和大量的底层集群架构打交道——从物理机、节点、Worker、Pod,到 Deployment、容器、副本数和集群,软硬件概念交织在一起,让人容易摸不着头脑。K8s 就如 Google 天才们的创造力一般,很强大,很 Geek。从顶层来看,初看 K8s 很复杂不知道能干什么;接着理解设计用意后觉得想法精妙,抽象层级逐步递进且科学有理;最后发现为了达到流畅使用的目的,内部的配置项足以消耗掉之前的惊喜——所有的自动化终归还是少不了人工的不断维护。

接下来记录第一笔手记。

首先,K8s 处理的目标是计算机集群算力,但表现形式是抽象的软件配置。K8s 的配置均可以写成 YAML 文件,一种纯文本的配置文件形式。K8s 试图将计算机集群通过层次抽象:物理机 -> 节点 node -> worker -> POD -> 容器 container 的关系,把应用存储到不同的物理服务器上,并管理起来。另一方面,K8s 由于在同一台物理机内「相对隔离(区分于虚拟机)」地运行了多个不同应用,同时在不同物理机内运行了多个相同的应用副本,因此应用间通信、POD 间通信及其对外通信,都需要软件形式的网络路由和交换机制。由于 POD 部署对硬件不透明,因此将软件路由与硬件实际路由做映射,以及维持应用副本的机制,对软件路由的设计提出了更高的应用复杂度。

在应用层级,为了将一个应用(微服务)以容器的方式在集群中部署,一组镜像(通常为一个应用的相关依赖)被放置在一个 POD 中。POD 是一个凭空造出来的概念,用来定义一个应用在高可用(HA)需求下的最小单位。一个高可用应用通常会有具有多个相同功能的算力同时支持,通过负载均衡的方式建立主备算力。因此 POD 通常会存在好几份,由 K8s 根据自身情况和 POD 配置,分配到同一集群中的不同节点。而如何创建 POD,就需要软件层次的抽象层级——Deployment(部署)来承接。一个部署(为了区别于部署动作,所以不称之为「一次」)描述了一个应用的完整依赖关系:端口映射、卷映射以及镜像版本等。运行一个部署配置,也就类似一个 docker-compose,可以把一组镜像拉起来并塞到同一个 POD 里,并且把建立副本 POD 的配置同时交给 K8s。

所以对于开发者而言,对于一个已经部署好的 K8s 集群,只需要打好镜像,写好 deployment,运行类似 kubectl apply deployment <depoly-script.yml> 命令,即可获得高可用模式下的应用集群。

不过对于运维者而言,部署集群节点以及调配网络配置,似乎是最复杂的事。