概述

Kubernetes proposal 包含了几篇架构方面的文档，可以读了之后一起总结。

不同角度的设计

architecture/architecture.md

控制面:
- RESTful API Server，所有的API必须是显式地表示为一个HTTP接口，client-go等的通信本质上也是基于HTTP API的
- Scheduler
- Controller Manager
外部存储：etcd，有且仅有api-server能直接操纵etcd，从某种程度上说，api-server是etcd的一个proxy
最核心管控面：kubelet，没有kubelet，api-server就仅仅只是一个CRUD Server，kubelet才是真正决定一个Pod能不能运行在Node上的最高组件，从这个角度看，kubelet的重要性要大于api-server
附件（add-on）：
- DNS
- Ingress
- Monitor
- GUI

architecture/architectural-roadmap.md

Roadmap 不仅要考虑Kubernetes自身的设计，还要考虑到Kubernetes上层和周边的生态系统。

使用经典分层架构，从下往上依次是：

Nucleus（核心层）：Kubernetes 自身的特性
Application Management Layer（应用管理层）：包含部署和路由2个方面，对应于Kubernetes提供的Deployment/StatefulSet和kube-proxy
Governance Layer（管理层）：包含高级自动化和策略增强等方面，对应于多租户能力，VPA/HPA，Quota，网络和存储策略
Interface Layer（接口层）：提供了给用户的接口，例如kubectl、client-go、GUI等
Ecosystem（生态）：看CNCF的landscape，这可太多了

对于Kubernetes这种平台的平台，其实分出明显的层次是很难的，Kubernetes 希望自身称为OS内核一样的地位，但从多年后的视角看，Kubernetes 真正重要的是它给出了一种Cloudnative的实现，并且确定了声明式API，不可变基础设施，运维自动化等一系列云原生共识。

随着Kubernetes自身核心组件的成熟，它可以解决大部分中小企业的运维问题，但是对于更大规模的企业，Kubernetes本身正逐渐成为一种设计规约，也许有组件会替代掉它的某些部分，但是不可能违背它确立的精神。

Component：

APIServer
etcd：Kubernetes唯一存储
Scheduler + scheduler framework
Kubelet
KubeDNS：将集群内部的域名解析为IP
Service：将一个或多个Deployment暴露
Ingress：将外部HTTP请求路由到Service上
Mutating/Validating Webhook：表现为mutatingwebhookconfigurations/validatingwebhookconfigurations对象，控制Pod对象的准入和修改

Interface：

关于API：

关于控制逻辑：

关于架构