Kubernetes总体架构
Master和Node
Kubernetes主要由以下几个核心组件组成：
- etcd
保存了整个集群的状态，用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；
- API Server
提供了资源操作的唯一入口，操作etcd的封装接口API，并提供认证、授权、访问控制、API注册和发现等机制；
- Controller Manager
集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作，比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的；
- Scheduler
负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
- Kubelet
负责管理本Node节点上的Pod的创建、修改、监控、删除等全生命周期，同时也负责Volume（CVI）和网络（CNI）的管理，定时“上报”本Node的状态信息到API Server里；
- Container runtime
负责镜像管理以及Pod和容器的真正运行（CRI）；
- kube-proxy
负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：
- Kube-Dns
负责为整个集群提供DNS服务
- Ingress
为服务提供外网入口
- Metrics Server
提供资源监控
- Dashboard
提供GUI
- Federation
提供跨可用区的集群
- Fluentd-Elasticsearch
提供集群日志采集、存储与查询
Node
Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。
Node Status包含的信息：
地址(Addresses)
状态(Condition)
容量(Capacity)
信息(Info)
Addresses
主机名: 节点内核报告的主机名。 可以通过kubelet –hostname-override参数覆盖。
外网IP: 通常是可从外部路由的节点的IP地址（可从群集外部获得）。
內网IP: 通常是仅在群集内可路由的节点的IP地址。
Condition
Conditions字段描述了所有正在运行的节点的状态。
| Node Condition | Description |
|---|---|
| OutOfDisk | True：如果节点上没有足够的可用空间来添加新的pod；否则为：False |
| Ready | True：如果节点是健康的并准备好接收pod；False：如果节点不健康并且不接受pod；Unknown：如果节点控制器在过去40秒内没有收到node的状态报告 |
| MemoryPressure | True：如果节点存储器上内存过低; 否则为：False。 |
| PIDPressure | True：如果进程存在压力 - 也就是说，如果节点上有太多进程; 否则为假 |
| DiskPressure | True：如果磁盘容量存在压力 - 也就是说磁盘容量低；否则为：False。 |
| NetworkUnavailable | True：如果未正确配置节点的网络; 否则为False |
Capacity
描述节点上可用的资源：CPU，内存以及可以在节点上调度的最大pod数。
Info
有关节点的一般信息，例如内核版本，Kubernetes版本（kubelet和kube-proxy版本），Docker版本（如果使用），操作系统名称。 信息由Kubelet从节点收集。
Pod
Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。
Kubernetes中的Pod使用可分两种主要方式：
Pod中运行一个容器。“one-container-per-Pod”模式是Kubernetes最常见的用法; 在这种情况下，你可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。
Pods中运行多个需要一起工作的容器。Pod可以封装紧密耦合的应用，它们需要由多个容器组成，它们之间能够共享资源，这些容器可以形成一个单一的内部service单位 - 一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
Service
在Kubernetes的世界里，虽然每个Pod都会被分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失，这就引出一个问题：如果有一组Pod组成一个集群来提供服务，那么如何来访问它呢？Service！
一个Service可以看作一组提供相同服务的Pod的对外访问接口，Service作用于哪些Pod是通过Label Selector来定义的。
拥有一个指定的名字（比如my-mysql-server）；
拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号，销毁之前不会改变，只能内网访问；
能够提供某种远程服务能力；
被映射到了提供这种服务能力的一组容器应用上；
Volume
Volume是Pod中能够被多个容器访问的共享目录。
Label
Label以key/value的形式附加到各种对象上，如Pod、Service、RC、Node等，以识别这些对象，管理关联关系等，如Service和Pod的关联关系。
Pod和Controller
Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
包含一个或者多个Pod的Controller示例：
Deployment
StatefulSet
DaemonSet
ReplicaSet
Jobs - Run to Completion
CronJob