从2020年在公众号上分享K8s学习笔记的时候开始，边写边学。每学习一个内容，记录总结就发布在公众号上。现在回过头来看，发现很多内容和知识点都写的太生硬了，很多名词不知道是干什么的直接翻译过来的。这就造成了文中缺乏温度，内容层次不够。所以尽量重新整理语言和文章段落，把K8s的知识写得更有层次，让大家更容易理解，也更有温度。不再是文档的翻译和一堆的概念。K8s基础介绍与实践--大纲前三个理论，后两个实践，理论也会有一些例子，让文章的内容不会太枯燥。其实之前写过一篇关于Docker和K8s的关系的文章，也算是进入K8s学习之前的一个热身，先分清两者的关系。本文着重介绍K8s的整体架构，给大家一个K8s的概貌。什么是K8sKubernetes（这个词太长，后来被K8s取代）是一种基于容器技术的分布式架构解决方案，起源于谷歌内部的大型集群管理系统——Borg，得到了开源社区的全力支持自2015年开源以来，IBM、惠普、微软、RedHat等行业巨头相继加入，成为后来的CNCF组织（CloudNativeComputingFoundation，云原生计算基金会）的第一个研究生项目。K8s拥有完善的集群管理能力，包括多级安全防护和接入机制、多租户应用支持能力、透明的服务注册和服务发现机制、内置负载均衡器、故障发现和自愈能力、服务滚动升级以及在线扩展、可扩展的资源自动调度机制、多粒度的资源配额管理能力。还提供了完善的管理工具，涵盖了开发、部署测试、运维监控等各个环节。一句话总结：它是一个集容器编排和集群调度管理为一体的大规模分布式系统解决方案。K8s是什么样子K8s并不是我们在现实中能看到和摸到的，所以初学者看了K8s是什么的描述后可能会感到一头雾水。所以在这里我试着描述一下K8s长什么样子。描述一个解决方案的外观，其实说白了就是它的整体架构是什么样的，由哪些核心部分组成，各个部分之间是如何交互的。我们先看一下K8s的整体结构。K8s整体结构K8s采用Master/WorkNode（原名Minion，后更名为Node）的结构。MasterNode（主节点）控制整个集群，WorkNode（从节点）为集群提供计算能力。用户可以通过命令行或网页控制台页面操作集群。下图可以清晰的展示出K8s的整体架构。K8s整体架构理解为K8s由master节点和worker节点组成。接下来我们一一展开，看看master节点和worker节点是由哪些组件组成的。Master节点Master节点是K8s集群的大脑，负责对外开放集群的API，对整个集群进行调度和管理。一个集群必须至少有一个Master节点。如果要在生产环境中实现高可用，还需要配置一个Master集群。下图描绘了主节点的内部结构。K8s主节点Master的内部结构主要包括三个组件：APIServer、Scheduler、Controllers，以及用于存储的etcd，用于存储整个集群的状态。etcd：由CoreOS开发，是一个高可用、强一致的key-value存储，为Kubernetes集群提供存储服务，类似于zookeper。它存储集群的整个配置和状态。主节点通过查询etcd来检查节点和容器的状态。APIServer：kubernetes最重要的核心组件之一，提供资源操作的唯一入口（其他模块通过APIServer查询或修改资源对象，只有APIServer才能直接操作etcd），提供认证、授权、访问控制、API注册和发现机制。Scheduler：负责资源调度，按照预定的调度策略将Pod（k8s中调度的基本单位）调度到对应的Node上。这里所说的Node是WorkNode。当然，如果是只有一个节点的集群，Master也会作为WorkNode。Controllers：通过APIServer查询要控制的资源对象的预期状态。它检查它所控制的对象的当前状态，以确保它们始终处于预期的工作状态。他们的工作包括，例如，故障检测、自动扩容、缩容、滚动更新等。我们可以接触到的控制器如下：DeploymentStatuefulSetServiceDaemonSetIngress具体是干什么的？我会放在下一篇文章-K8s面向对象中再详细介绍。是的，如果你要用K8s，你就得面向对象，这很糟糕。到时候结合实例来看。下面继续看一下K8s工作节点的内部结构。工作节点K8s集群的工作节点可以是物理机也可以是虚拟机。Node上运行的主要K8s组件有kubelet、kube-proxy、ContainerRuntime、Pod等。K8s工作节点的内部结构。K8s集群的每个工作节点都会运行一个kubelet程序来维护容器的生命周期。它接收并执行Master节点发来的指令，管理节点上的Pod和Pod中的容器。它还负责卷(CVI)和网络(CNI)的管理。每个kubelet程序都会在APIServer上注册节点自身的信息，定期向Master节点报告自身节点的资源使用情况，并通过cAdvisor监控节点和容器的资源情况。节点通过运行kubelet，将自身的CPU、RAM、存储等计算机资源变成集群的一部分，相当于将它们放入集群统一的资源管理池中，交给Master统一部署.ContainerRuntime负责与容器实现通信，完成从容器镜像库中拉取镜像等操作，进而启动和停止容器。引入容器运行时的另一个原因是让K8s架构兼容特定的容器实现。再加上，Docker不仅可以运行在K8s上，还可以让K8s的开发按照自己的节奏进行。如果你想在我的生态系统中运行容器，请实现我的CRI（容器运行时接口）。ContainerRuntime只负责调用CRI中定义的方法完成容器管理，不单独进行dockerrun等操作。这也是在K8s1.5之后发现Docker限制了它的发展时引入的。PodPod是K8s中最小的调度单元。我们的应用程序运行在容器中，容器被打包在pod中。一个Pod中可以有多个容器，也可以有多个容器。没有统一的标准，是单个还是多个，取决于要运行的应用程序的性质。但是一个Pod中只有一个主容器，其余都是辅助主容器。例如，服务网格Istio的Envoy网关运行在Pod的辅助容器中，实现流量控制。这是K8s容器设计模式中最常用的模式：sidecar。顾名思义，sidecar就是我们可以在一个Pod中启动一个辅助容器来完成一些独立于主进程（主容器）的工作。kube-proxy为集群提供内部服务发现和负载均衡，监听APIServer中Servicecontroller及其背后端点的变化，通过iptables等实现Service的虚拟IP、访问规则、负载均衡方法。小结本文主要介绍K8s的整体架构，给大家一个K8s的概貌。下一节我们来聊一聊K8s的面向对象以及我们可以接触到的常见控制器对象。此时此刻，当你看到这句话的时候，你的心情可能是：“纳尼，这家伙也是面向对象的？面向对象的，怎么老是你？”是的，K8s也是面向对象的，而且讲的很透彻，就像某种语言说的一切都像对象一样透彻。但是因为是面向对象的，所以用面向对象的方式来思考这些东西，就会很容易理解。毕竟，我们每天都必须“面向对象”，不是吗:)。
