K8S(一)基本概念

目录

k8s架构

主要组件（高可用集群副本最好为奇数）

插件

基本概念

pod

为什么是pod：

pod分类：

控制器的类型

1.ReplicationController & ReplicationSet & Deployment

2.HPA（平滑扩展）

3.StatefulSet

4.DaemonSet

5.Job & Cron Job

k8s网络通信模式

Flannel

pod的网络通讯

 k8s的网络结构

---

k8s架构

主要组件（高可用集群副本最好为奇数）

api server：所有访问统一入口

ControllerManager(控制器):维护副本的期望数目

scheduler：负责介绍任务，选择合适的节点进行分配任务

etcd：键值对数据库，存储k8s集群所有重要信息（持久化）

kubelet：直接容器引擎交互实现容器的生命周期管理

kube proxy：负责写入规则到IPTABLES，IPVS 实现服务映射访问

插件

CoreDNS：可以为集群中的svc创建a记录（域名ip对应关系解析）

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

ingress controller：官方只能实现4层代理，ingress可以提供七层代理

Fedetation：提供一个可以跨集群中心多k8s统一管理功能

Prometheus：提供一个k8s集群的监控能力

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

基本概念

pod

为什么是pod：

在传统dokcer中每个容器相互隔离，有自己的地址，但对于lnmp中的nginx和php应该放一起只能将两个镜像封装到一起或者一个采用另一个的网络栈，但相对来说存在安全性问题。但对于pod，开启一个pod就会启动一个容器pause后面在封装的容器会共用pause的网络栈和存储卷。网络栈：后面的容器就不再有自己独立的ip地址，而且当中的进程不会隔离。但注意不能使用同一个端口号，不然pod起不来或在无限重启。

pod分类：

1.自主式pod

2.控制器管理的pod

控制器的类型

1.ReplicationController & ReplicationSet & Deployment

ReplicaSet 是 ReplicReplicationController 的升级版，ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。

ReplicationSet 确保任何时间都有指定数量的 Pod 副本在运行。

虽然 ReplicaSets 可以独立使用，但今天它主要被 Deployments 用作协调 Pod 创建、删除和更新的机制。 Deployments支持滚动更新，但并不支持pod的创建。

2.HPA（平滑扩展）

仅适用于 Deployment 和 ReplicaSet,在v1版本中仅支持根据 pod 的 cpu 利用率扩展缩小容器，在v1alpha版本中，支持根据内存和用户自定义的metric扩展缩小容器。解决无状态服务问题。

3.StatefulSet

为了解决有状态服务问题。

稳定的持久化存储，pod 死亡之后重新调度还能访问到相同的持久化数据，基于PVC来实现。

稳定的网络标识，pod 重新调度之后 podname 和 hostname 不变。基于Headless Service（即没有Cluster IP 的 Serveice）来实现。

有序部署，有序扩展，有序回收。在运行该 pod 之前的 pod 都是处于 ready 或者 runnning 的状态。

4.DaemonSet

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

eg：在每个 node 运行日志收集，监控等

5.Job & Cron Job

Job:负责批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。运行脚本的时候有自己的纠错能力。如果运行的脚本没有以0的代码退出，他会重新执行该程序。

CronJob：Cron Job时在特定的时间 循环创建 Job 来实现的（也是 分 时 日 月 周）  一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

k8s网络通信模式

Flannel

Kubernetes 的网络模型中所有的 pod 都在一个可以直接联通的扁平的网络空间中

CentOS 的 Flannel 针对 Kubernetes 设计的网络规划服务。让集群中不同节点主机创建的 Docker 容器都具有全局唯一的虚拟 IP 地址。而且在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过该网络覆盖可以将数据包原封不动的传递到目标容器中。

ETCD 和 Flannel 关联：

存储管理Flannel可分配的 ip 地址网段资源

监控 ETCD 中每个 pod 的实际地址，并在内存中建立维护 pod 的节点路由表

pod的网络通讯

同一个 pod 内的多个容器之间：io（内部共用pause的网络栈）

各 pod 之间的通讯： Overlay Network

 flannel支持多种后端：

Vxlan vxlan        //报文封装，默认 Directrouting       //直接路由，跨网段使用vxlan，同网段使用host-gw模式。

host-gw：    //主机网关，性能好，但只能在二层网络中，不支持跨网络，                如果有成千上万的Pod，容易产生广播风暴，不推荐

UDP：            //性能差，不推荐 

配置flannel： # kubectl -n kube-system edit cm kube-flannel-cfg  

net-conf.json: |    

        {

               "Network": "10.244.0.0/16",      

                "Backend": {        

                        "Type": "vxlan",        

                        "Directrouting": true

                     }

         }

 kubectl get pod -n kube-system |grep kube-flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'                                        #######更新flannel

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

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

外网访问 Pod：Service

 k8s的网络结构