K8s新手系列之K8s架构

应用部署方式演变

在部署应用步伐的方式上，主要经历了三个时代：
传统部署

互联网早期，会直接将应用步伐部署在物理机上
优点：简单，不需要其它技术的参与缺点：不能为应用步伐定义资源使用界限，很难合理地分配计算资源，而且步伐之间轻易产生影响
虚拟化部署

可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境
优点：步伐环境不会相互产生影响，提供了一定程度的安全性缺点：增加了操纵体系，浪费了部门资源
容器化部署

与虚拟化类似，但是共享了操纵体系
优点：可以包管每个容器拥有自己的文件体系、CPU、内存、进程空间等运行应用步伐所需要的资源都被容器包装，并和底层基础架构解耦容器化的应用步伐可以跨云服务商、跨Linux操纵体系发行版进行部署

容器化部署方式给带来很多的便利，但是也会出现一些问题，好比说：

• 一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器
  
• 当并发访问量变大的时候，怎么样做到横向扩展容器数目
  

这些容器管理的问题统称为容器编排问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：

• Swarm：Docker自己的容器编排工具
  
• Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用
  
• Kubernetes：Google开源的的容器编排工具
  
  
  
  

K8s简介

K8s全称叫做kubernetes。是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的机密武器----Borg体系的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。
kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的步伐，来对节点中的容器进行管理。目的是实现资源管理的主动化，主要提供了如下的主要功能：

• 自我修复：一旦某一个容器崩溃，可以或许在1秒中左右敏捷启动新的容器
  
• 弹性伸缩：可以根据需要，主动对集群中正在运行的容器数目进行调整
  
• 服务发现：服务可以通过主动发现的形式找到它所依赖的服务
  
• 负载均衡：假如一个服务起动了多个容器，可以或许主动实现哀求的负载均衡
  
• 版本回退：假如发现新发布的步伐版本有问题，可以立即回退到原来的版本
  
• 存储编排：可以根据容器自身的需求主动创建存储卷
  

K8s架构描述

一个K8s集群主要由控制（master）节点和工作（node）节点构成，每个节点上都会安装不同的组件。
master节点：

master节点是整个集群的控制平面，负责集群的决策、管理，其由几个组件构成：

• kube-apiserver：k8s集群资源操纵的唯一入口，接收用户通过kubectl输入的命令，提供认证、授权、API注册和发现等机制
  
• etcd：分布式键值存储数据库，长期化保存集群所有状态数据（如 Pod、节点、配置等），简单点来说就是负责存储集群中各种资源对象的信息
  
• kube-scheduler：负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
  
• kube-controller-manager：负责维护集群的状态，好比步伐部署安排，故障检测、主动扩展、滚动更新等，简单点来说就是确保集群实际状态与期望状态一致。
  
• cloud-controller-manager（可选）：对接云服务商（如 AWS、Azure、GCP），处理云平台相关逻辑。管理负载均衡器、存储卷、节点生命周期（如主动扩缩容）。仅在使用云服务时启用，本地环境无需此组件。
  

node节点：

node节点是整个集群的数据平台，负责为容器提供运行环境，简单点来说node节点就是负责干活的，其由几个节点构成：

• kubelet：管理Pod的生命周期和上报当前节点的状态。
  
• kube-proxy：负责Pod的访问路由及负载均衡实现
  
• 容器运行时环境：负责拉取镜像、运行容器。其中主要包罗Docker、Containerd等组件，通过 CRI（Container Runtime Interface）与 kubelet 交互。
  

K8s单master架构

下图是一个K8s单master架构图，当一个master节点宕机之后，整个集群处于不可用的状态。

K8s多master架构

下图是一个K8s多master架构图，当一个master节点宕机之后，可以通过VIP飘移实现集群的高可用

K8s常用术语

OCI:

OCI（Open Container Initiative）是指开放容器标准，它是一个轻量级、开放的管理结构，致力于围绕容器格式和运行时创建开放的行业标准
通过支持OCI规范，Kubernetes可以与多种容器运行时兼容，这使得K8s在容器编排和管理方面更加灵活和强大。
CRI

CRI（Container Runtime Interface）是Kubernetes定义的一组与容器运行时进行交互的接口。
CRI是Kubernetes用来与容器运行时进行交互的标准接口。它定义了一套RPC（长途过程调用）API，这些API被用来管理容器的生命周期。
目前实现了CRI spec的Runtime有Docker Engine、containerd、CRI-O、Mirantis Container Runtime（Docker企业版）等。
已经弃用的有docker-shim
2020年k8s宣布弃用docker-shim，2022年k8s的1.24版本正式弃用docker-shim，这个时候假如容器使用docker的话，需要单独部署docker-shim。
所以在1.24版本之后推荐使用containerd做为容器运行时环境
CNI:

CNI（Container Network Interface）是一个规范和框架，它答应Kubernetes通过插件化的方式集成各种网络解决方案，以实现集群内部容器之间的网络通信。
支持的网络模式：Overlay Network，Underlay Network，flannel，calico，cannel，cilium

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。