01-k8s基础概念

组件介绍：

架构概览图

master节点需安装

1、apiserver：所有服务访问的统一入口（压力大）

2、scheduler：任务调度器，1:将不同请求和调度到不同节点2:选择node节点应用部署

3、controller manager ：replication Controller（RC，后为RS）：管理node中的pod，处理集群中常规后台任务删除和增加pod，维持副本期望数目,rs支持label方式进行标签选择，最后使用deployment。并被deployment取代

deployment支持热更新

4、ETCD：键值对数据库，数据化持久化方案

raft：存储读写信息（CoreOS公司开发，同时CoreOS公司开发了Flannel插件）

WAL：存储日志备份：增量备份和全量备份

snapshot：快照

node节点需要安装：

kubelet
操作管理docker容器，运行环境，接口，维持pod生命周期，master派到node节点的代表，调用CRI接口控制容器（docker）

kube proxy
网络代理，负载组件，负责写入规则至IPTABLES、IPVS，实现pod与pod的访问

docker

其他重要插件：

INGRESS CONTROLLER：官方只能实现四层代理（IPVS），INGRESS可以实现七层代理，从而支持主机名域名（基于域名）

COREDNS：可以为集群中的SVC创建一个域名IP的对应关系解析（内部网络端点固定化，因为底层容器会导致内部IP的变化，可以使用域名动态绑定到最新的IP上，防止pod失联）

DASHBOARD：给K8s集群提供一个B/S结构访问体系

FEDETATION：提供一个可以跨集群中心多K8S统一管理功能(通过kubectl指定连接不同的k8s集群)

普罗米修斯：提供一个K8s集群的监控能力

ELK：集群日志统一分析介入平台

pod概念

pod中的概念

pod基本概念：
一组容器的集和
pod中的容器可以共享网络，pod中的lnmp中nignx寻找php只需要输入localhost:9000就可以互相通信
pod是一组容器的集和，pod中的容器还可以共享存储

pod是网络和存储的基础单位，也是k8s管理的最小单位:

pod中网络结构：

pod中会先创建一个pause容器，初始化网络栈，挂载网络卷，然后会初始化主容器(MainC)其他容器(MainC)，和pause共享网络栈

分类：
自主式Pod（一旦重启就会死掉）
控制器管理的pod

有状态和无状态：
有状态：需要有IP、存储进行限定
无状态：拿来就能用

管理pod的控制器：

控制组件的更新历程：
replication ControllerManager（RC）：用来确保容器应用的副本始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来代替，而如果异常多出来的容器也会自动回收，新版本使ReplicaSet（RS）取代

ReplicaSet（RS）支持集和式的selector（标签选择器的诞生，支持集合运算）

Deployment自动管理ReplicaSet，滚动更新和回滚

HPA（Horizontal Pod Autoscaling）

通过监控Pod的资源利用率，当pod CPU利用率过高（>80%）时，创建pod，最大不能大于10，当cpu利用率小于阈值，可以减少到2，以节省资源

仅适用于deployment和Replicaset

statefulset：是为了解决有状态服务的问题

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现

稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现

有序的扩容缩，有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现（比如nginx+apache+mysql应该先部署mysql，然后部署apache，最后部署nginx）

有序收缩，有序删除（即从N-1到0）

DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

使用 DaemonSet 的一些典型用法：
运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、ceph
在每个 Node 上运行日志收集 daemon，例如fluentd 、logstash
在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond

Job
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

CronJob
Cron Job 管理基于时间的 Job，即：
1、在给定时间点只运行一次
2、周期性地在给定时间点运行

pod服务发现

pod通讯方案

网络通讯方式

如何解决跨越node不同pod之间的通信？

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟IP地址。而且它还能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内

不同node地址即192.168.66.11(12)代表node的地址，不同的Flanneld会在两台物理机上创建自己的不同的IP网段（10.1.15.0\16）,（10.1.20.0\16）docker0会基于Flanneld进行设定

ETCD 之 Flannel 之间的关联：
存储管理 Flannel 可分配的 IP 地址段资源（存储到数据库，防止IP冲突）
监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表

总结：

同一个 Pod 内部不通容器间通讯：同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈NameSpace，直接通过IO通讯

Pod1 至 Pod2：
Pod1 与 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2，不需要经过 Flannel

Pod1 与 Pod2 不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问（Flannel可以实现向etcd注册网段，实现一个node绑定一个网段，从而通过UDP数据包二次封装通过封装和解包实现通讯）

Pod 至 Service 的网络：
目前基于性能考虑，全部为 iptables （或者lvs）维护和转发