关于kubernetes:Kubernetes架构概述

10次阅读

共计 2961 个字符，预计需要花费 8 分钟才能阅读完成。

自从在生产环境引入容器当前，目前直观感触最大的两个长处:

部署疾速，挪动、扩大便捷。
节俭了 15% 左右的硬件资源。

随着线上容器数量的增多，也遇到了治理工作量加大的状况，便呈现了前文的 DockerSwarm 的应用调研以及 portainer 工具的引入，在治理难度上确实加重很多。

然而容器治理的精华：主动实现服务的部署、更新、卸载和扩容、缩容 等，DockerSwarm 并没有提供。包含将来想进行服务基础设施和利用拆散，并且从现有的基于 springcloud 的 Java 语言微服务转向语言无关的云原生微服务的落地等等指标都指向了 Kubernetes。接下来的次要学习方向也放在这里，摸索云原生的生态链，一边学习一边总结。

对于 Kubernetes 的学习思路如下：

首先理解大略
实操部署集群
深入研究原理，浏览相干书籍

Kubernetes 是谷歌开源的容器集群管理系统，是 Google 多年大规模容器治理技术 Borg 的开源版本，官网称其是：

Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.

用于主动部署、扩大和治理“容器化（containerized）应用程序”的开源零碎。

次要性能包含：

基于容器的利用部署、保护和滚动降级
负载平衡和服务发现
跨机器和跨地区的集群调度
主动伸缩
无状态服务和有状态服务
宽泛的 Volume 反对
插件机制保障扩展性

下图清晰表明了 Kubernetes 的架构设计以及组件之间的通信协议。

图中一些协定名称后续再深究，临时先理解大略。

上面是更形象的一个视图：

Kubernetes 是属于 主从设施模型（Master-Slave 架构），在 Kubernetes 中，主节点个别被称为Master，而从节点则被称为Node。

Master 和 Node 是别离装置了 Kubernetes 的 Master 组件和 Node 组件的实体服务器，每个 Node 都对应了一台实体服务器（尽管 Master 能够和其中一个 Node 装置在同一台服务器，然而倡议 Master 独自部署），所有 Master 和 Node 组成了 Kubernetes 集群，同一个集群可能存在多个 Master 和 Node，满足高可用诉求。

Master节点主要职责包含：

集群的“大脑”，负责管理所有节点（Node）。
负责调度 Pod 在哪些节点上运行。
负责管制集群运行过程中的所有状态。

Master组件次要包含：

API Server

又叫 kube-apiserver，kube-apiserver 是 Kubernetes 最重要的外围组件之一，次要提供以下的性能
- 提供集群治理的 REST API 接口，包含认证受权、数据校验以及集群状态变更等
- 提供其余模块之间的数据交互和通信的枢纽（其余模块通过 API Server 查问或批改数据，只有 API Server 才间接操作 etcd）
Scheduler

kube-scheduler 负责调配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查问还未调配 Node 的 Pod，而后依据调度策略为这些 Pod 调配节点（更新 Pod 的 NodeName 字段）。
Controller Manager

Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。

Controller Manager 有很多具体的 Controller，例如：Node Controller、Replication Controller、Endpoints Controller、Service Account and Token Controllers、Service Controller、Volume Controller 等等。
etcd

etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）

etcd 存储了 Kubernetes 的要害配置和用户配置，Kubernetes 中仅 API Server 才具备读写权限，其余组件必须通过 API Server 的接口能力读写数据（见 Kubernetes Works Like an Operating System）。

本图来自 HOW DO APPLICATIONS RUN ON KUBERNETES

Node节点主要职责包含：

负责管理所有容器（Container）。
负责监控 / 上报所有 Pod 的运行状态。

Node节点次要组件包含：

kubelet

每个 Node 节点上都运行一个 Kubelet 服务过程，默认监听 10250 端口，接管并执行 Master 发来的指令，治理 Pod 及 Pod 中的容器。每个 Kubelet 过程会在 API Server 上注册所在 Node 节点的信息，定期向 Master 节点汇报该节点的资源应用状况，并通过 cAdvisor 监控节点和容器的资源。
kube-proxy

每台机器上都运行一个 kube-proxy 服务，它监听 API server 中 service 和 endpoint 的变动状况，并通过 iptables 等来为服务配置负载平衡（仅反对 TCP 和 UDP）。
Container Runtime

即装置了容器化所需的软件环境确保容器化程序可能跑起来，比方 Docker Engine。
Logging Layer

Logging Layer 负责采集 Node 上所有服务的 CPU、内存、磁盘、网络等监控项信息。
Add-Ons：

Kubernetes 治理运维 Node 的插件组件，例如：
- CoreDNS 负责为整个集群提供 DNS 服务
- Ingress Controller 为服务提供外网入口
- Prometheus 提供资源监控
- Dashboard 提供 GUI
- Federation 提供跨可用区的集群

这部分也就是先理解一下，Kubernetes 设计理念和性能其实就是一个相似 Linux 的分层架构，如下图所示：

核心层：Kubernetes 最外围的性能，对外提供 API 构建高层的利用，对内提供插件式利用执行环境
应用层：部署（无状态利用、有状态利用、批处理工作、集群利用等）和路由（服务发现、DNS 解析等）
管理层：零碎度量（如基础设施、容器和网络的度量），自动化（如主动扩大、动静 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
生态系统：在接口层之上的宏大容器集群治理调度的生态系统，能够划分为两个领域
- Kubernetes 内部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 利用、ChatOps 等
- Kubernetes 外部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群本身的配置和治理等

正文完