Kubernetes 01

MESOS：APACHE 分布式资源管理框架   2019-5  Twitter退出，转向使用Kubernetes

Docker Swarm 与Docker绑定，只对Docker的资源管理框架，阿里云默认Kubernetes

Kubernetes：Google 10年的容器化基础框架，borg系统   Go语言对borg系统进行翻写，就是Kubernetes

        特点：轻量级   消耗的资源少

                   开源

                   弹性伸缩

                   负载均衡

blog组件

brogcfg：通过文件访问    command-line tools：通过工具访问   web browsers：通过浏览器访问

将任务交给BrogMaster，然后将任务分发出去给Broglet（不同的节点），将数据写入Paxos数据库，然后Broglet监听数据库 

高可用集群副本数据最好是>=3的奇数个

k8s:

scheduler：调度器，负责接收任务，将任务调度到不同的合适的node中。scheduler将任务交给api server，然后api server将任务交给etcd（scheduler并不会与etcd直接交互） 

api server：所有服务访问的统一入口

reolication controller：控制器，维持副本的期望数目

etcd：可信赖分布式键值对数据库，为整个分布式集群存储一些关键数据，协助分布式集群的正常运转，持续化的数据

        不同版本：v2：写入内存中（已在Kubernetes v1.11中弃用）    v3:引入本地的卷的持久化操作

etcd内部架构图：

采用HTTP Server的形式，进行c/s构建

Raft：存放所有读写的信息

WAL：进行日志备份，预写日志，如果想对信息进行更改，先生成一个日志，可以在一段时间后进行完整备份

kuberlet：直接与容器引擎进行交互实现容器的生命周期管理，与docker进行交互，操作docker创建一些容器，维持pod的生命周期

kube proxy：负责写入规则至IPTABLES  IPVS,负载均衡，默认操作防火墙，实现Pod之间的映射访问 

其他插件：CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析

                  Dashboard：给k8s集群提供一个B/S结构的访问体系

                  Ingress Controller：官方只能实现四层代理，Ingress可以实现七层代理

                  Federation：提供一个跨集群中心多k8s的统一管理功能

                  Prometheus：提供集群的监控能力

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

Pod

自主式Pod：不是被控制器管理的Pod

控制器管理的Pod

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代，如果异常多出来的容器也会自动回收

在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController

它们没有本质的不同，只是ReplicaSet支持集合式selector

虽然ReplicaSet可以独立使用，但一般还是建议使用Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（RS不支持滚动更新，但是Deployment支持）

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：

        稳定的持久化存储，即Pod重新调度后还是能访问待相同的持久化数据（数据不会丢失），基于PVC来实现

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

        有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现

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

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

使用DaemonSet的一些典型用来：

• 运行集群存储daemon，例如在每个Node上运行glustered、ceph
• 在每个Node上运行日志收集daemon，例如fluented、logstash
• 在每个Node上运行监控daemon，例如Prometheus Node Exporter

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

Cron Job管理基于时间的Job：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

网络通信模式

Kubernetes的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假定这个网络已经存在，而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes

同一个Pod内的多个容器之间：共用同一个网络栈，网络栈的IO

各Pod之间的通讯：Overlay Network

Pod与Service之间的通讯：各节点的Iptables规则

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

Flannel启动之后会向etcd中插入可以被分配的网段，

etcd存储管理Flannel可分配的IP地址段资源，监控etcd中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

总结：

同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈

Pod1至Pod2：如果Pod1与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行，将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问

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

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

Pod到外网：Pod向外网发送请求，查找路由表，转发数据包至宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求

外网至Pod：Service

注意真实的物理网络只有节点网络，Pod网络与Service网络都是虚拟网络