kubernetes架构（简称K8s）提供了面向应用的容器集群部署和管理系统。开发人员可以不必承受编排物理/虚拟计算，网络和存储设施的负担，专注于以容器为中心的原则上进行自我运营。

一、容器和镜像

容器可以简单理解为一个受到限制的Linux进程,它通过Namespace进行资源隔离，使运行在同一宿主机上的容器不能访问彼此的资源，通过Cgroups对进程使用的计算机资源进行限制。容器项目Docker可以将容器的可执行文件、库文件、配置都打成一个包（也就是Docker镜像），由于这个包包含了系统和运行环境的信息，所以在任何服务器上都可以直接运行起来，他们和制作者当时制作好的环境是一样的，这就是容器的技术的强一致性，真正实现了Build once, Run anywhere.

Linux操作系统是由内核空间和用户空间组成的。Docker的镜像的原理是直接利用宿主机的内核空间kernel，自己只需提供用户空间的系统文件rootfs，可以做到非常的轻量。

镜像采用了分层结构，每安装一个软件，就会在现有的镜像基础上增加一层（增加一个新镜像）。所有镜像都可以被多容器共享。在容器启动时，一个新的可写层（被称为容器层）会被加载到镜像的顶部（容器层之下的被叫做镜像层）。只有容器层是可写的，镜像层是仅只读的，所以无论一个容器如何对镜像进行改动，其他容器都不受影响。

二、Pod

Pod是K8s中你可以创建和部署的最小单位，代表集群中运行的进程，应用的一个具体实例。Pod中封装着应用的容器（有时候是好几个容器），它们一起共享资源，网络和依赖，总是被分配在一个Node上被同时调度。

2.1 存储资源

可以为一个Pod指定多个共享的Volume（存储卷）。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

2.2 网络资源

每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用 localhost 互相通信。Pod 中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。

2.3 Pod的使用和管理

Pod一旦被创建以后就会被调度到集群的Node上直到Pod被终止。Pod自身没有自愈能力，一旦程序被终止（无论主动还是被动），它就会被删除。

Controller层是K8s用于创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。如果Pod所在的Node故障，Controller就会把它调度到其他健康的Node上。

三、云原生

由CNCF（云原生计算基金会）的定义来看，云原生是使用了容器、Service Mesh、微服务、immutable infrastructure和声明式API的技术。

它是一种指导软件和基础设施架构的架构设计的思想，基于这个思想构建出来的应用和基础设施可以天然地和“云”集成在一起。从技术层面上看，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。简单的说，就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时，构建系统的成本更低。

无论是K8s还是Service Mesh、容器，它们都是一种云原生领域的一种落地实践。

四、微服务架构

了解完以上的这些基础概念，可以简单地描述一下微服务架构的组成实现。

Kubernetes系列随笔 作者：谦寻 仅作为自学资源使用，大量引用上述博客，特此注明