科普小课堂 篇四：科普小课堂 篇四：K8s是什么？服务容器化的改造——从蒙圈到套娃！

前言：

在IT圈，如果不搞K8s，那基本都不好意思出门见同行，作为一种开源的容器编排平台，K8s已然成为了时下绝对热门技术。但K8s究竟是什么？如何将服务K8s化？以及K8s与Docker二者之间有哪些区别和联系？

K8s是什么？

首先讲一个冷知识：Kubernetes的ubernete总共是八个字母，K8s是Kubernetes的缩写形式，其逻辑是将K后面的八个字母替换为8，K8s由此而来。

有意思的是，K8s仍然发音为Kubernetes，因为发音K-8-s并不能节省太多时间。目前在Kubernetes官方文档中也提到了K8s的字眼。

Kubernetes是希腊语，意思是就像舵手驾驶一艘船一样，来管理一个项目，这就是 Kubernetes徽标类似于舵（船的方向盘）的原因，其包管理器称为Helm。

从技术角度看，Kubernetes集群架构以及相关的核心组件如下图所示：一个 Kubernetes 集群一般包含一个 Master节点和多个Node节点，一个节点可以看成是一台物理机或虚拟机。

Master

Master是K8s的集群控制节点，每个K8s集群里需要有一个Master节点来负责整个集群的管理和控制，基本上K8s所有的控制命令都是发给它，由它来负责具体的执行过程。Master节点通常会占据一个独立的服务器，如果它不可用，那么所有的控制命令都将失效。

Node

除了Master，K8s集群中的其它机器被称为Node节点，Node节点是K8s集群中的工作负载节点，每个Node都会被Master分配一些工作负载，当某个Node宕机时，其上的工作负载会被Master自动转移到其它节点上去。目前，K8s的能力及优势主要围绕以下四点展开：

1：一个基于容器环境（Docker/Containerd等）支持跨多台异构主机环境的资源编排平台；

2：基于YAML声明式管理资源，控制面通过监控部署应用的最终状态，来确保服务始终按照部署的要求来运行；

3：快速、按需扩展容器化应用及其资源，并自动对应用实施状况检查和自我修复；

4：开放CNI/CSI/CRI标准协议，提供第三方在网络、存储以及虚拟化上接入的能力，也在开源分享上提供了想象力。

如何将服务K8s化？

1.Deployment

在wxapi-system命名空间下，使用wxapi v0.0.1版本创建一个2个副本的无状态应用命名为wxapi，对外暴露一个8888端口，并打上一个app=wxapi的标签。

2.Service

在wxapi-system命名空间下，为上面被迫打上app=wxapi标签的应用，创建一个从内部服务8888端口映射到外部8888监听端口的服务发现Service。其中，NodePort和ClusterIP的区别在于是否能被集群外部访问到。这里你还可以了解下port-forward这个技能。

3.Ingress

在wxapi-system命名空间下，创建一个类似nginx/conf/wxapi.conf的配置，指向xxx.net域名的/*location，并将upstream反向代理到刚刚配置的wxapi service服务发现。

4.访问过程

5.Health Check

最后回过头，给刚刚创建的无状态应用，加上服务ready以及存活健康监控，这里偷懒地只是检测端口是否正常。原生K8s支持shell script/HTTP/TCP等检测方式。

关于K8s化，在这里划个重点：

K8s化的核心在于，如何从日常敲命令或者拷贝修改配置文件的方式，转换成模板渲染的模式，输出最终的声明结果内容，达到最终能更加快速、高效以及标准化无差别地搭建好服务的技能点。

除了写YAML

开发人员还能做哪些？

1.Helm Charts

Helm对于Kubernetes来说，就相当于yum对于Centos，可以理解为Ansible这样的工具，主要是用来帮助定义、安装和升级复杂的Kubernetes应用程序。

Charts用来封装Kubernetes原生应用程序的YAML文件，可以在部署应用的时候自定义应用程序的一些metadata，便与应用程序的分发。

Helm Charts主要作用体现在，应用程序封装/版本管理/依赖检查/便于应用程序分发。

2.CRD(CustomResourceDefinition)

Kubernetes v1.7版本后为了提高可扩展性，让开发者去自定义资源的一种方式。

CRD资源可以动态注册到集群中，注册完毕后，用户可以通过kubectl来创建访问这个自定义的资源对象，类似于操作Pod一样。

不过需要注意的是CRD仅仅是资源的定义而已，需要一个Controller去监听CRD的各种事件来添加自定义的业务逻辑。

像Deployment/Daemonset这些也可以认为是一种CRD资源，只是K8s默认自带了而已。

3.Operator

可以看作是CRD和Controller的一个结合。

Operator是一个特定的应用程序的控制器，通过扩展KubernetesAPI资源（也就是CRD），以代表Kubernetes用户创建、配置和管理复杂应用程序的实例，通常包含资源模型定义和控制器。

Operator通常是为了实现某种特定软件（通常是有状态服务）的自动化运维。核心在于Controller的逻辑设计，通过ListAndWatch来执行AddFunc/UpdateFunc/ DeleteFunc行为，进而达到操作集群资源对象，以达到最终声明结果的目的。

目前，常见的Operator开发工具有：Operator SDK、Kubebuilder。

4.Scheduling Framework

以往的调度器有直接修改kube-scheduler源码、额外部署完全独立的调度器和调度器扩展程序kube-scheduler-extender等方式。

Kubernetes Scheduler提供的一个新的可插入式架构。可简化调度程序的自定义，它向现有的调度程序中添加了一组新的pluginAPI。插件被编译到调度程序中。

当前业界常见的调度器开发，大多都是结合Prometheus指标或者混合云异构资源场景，去实现内部自有的调度算法，提升整个集群资源的利用率，甚至是超卖场景。

写在最后

随着K8s作为容器编排解决方案变得越来越流行，不少从业者开始拿Docker和K8s进行对比。其实二者并非直接的竞争对手，而是彼此相互依存。Docker是一个容器化平台，而K8s是Docker等容器平台的协调器。

虽然K8s给技术开发人员打开了一扇门，带来很多优秀的设计、优秀的理念，但是这些设计和理念也是有自己的适用的场景，并不是放之四海而皆准。我们不应该盲从，试图一切都要follow K8s的设计和规则，而抛弃之前的优秀设计理念。

/ END /