Kubernetes系统基础

Docker集群管理与编排的方法

• docker_compose（单机编排）+ docker_swarm（整合资源池）+ docker_machine（快速安装docker）
• mesos（AS旗下，IDC级别的硬件编排，但接口不是容器接口）+ marathon（容器接口）
• kubernetes
• 孕育而生的概念：DevOps、MicroServices、Blockchain

devops概念

• CI/CD持续集成、持续交付、持续部署
• 持续集成：用户提交代码后，自动构建、自动构建测试环境并测试
• 持续交付：自动打包到共享的文件服务或仓库中
• 持续部署：自动触发发布到线上
• 整个环境持续自动进行即 devops，其中自动部署是极其困难的，但 pod 技术极好的解决了这个问题
• 大部分复杂的 devops 构建在 pod 编排工具之上
• devops 是文化、是自动化的精神，是打破 dev 和 ops 墙壁的方式

kubernetes架构

• Go 语言重铸的 Borg 系统
• 大部分云厂商已经原生支持 kubernetes，甚至有些厂商提供 pod 即服务
• 自动装箱（基于某些约束完成 pod 部署，且不影响使用），自动修复，自动水平拓展、自动服务发现和负载均衡、自动发布与回滚
• 密钥和模拟配置中心、存储编排（存储卷动态供给）、任务的批量处理运行
• master/nodes 模型的集群，整合资源池，master组件负责接收用户请求，由调度器通过算法调度到符合条件的 node，再由 node 上的容器引擎创建出 pod

master核心组件

• APIServer：负责接收、解析和处理请求
• schedule： 调度器，负责观测每个 node 上计算和存储资源，并根据用户申请的 pod 所需的最低资源做调度分配最终生成pod 的node，schedule 分配资源有两级调度：预选、筛选那些节点符合标准，再根据优选算法从预选的节点中选择出最终落盘
• controllermanager：确保node上的controller正常，而 controllermanager 处于 master 之上，master冗余确保高可用
• etcd：键值存储、类似zk可以选举leader等，为master提供共享存储，因为存储集群内所有对象的动态信息所以需要高可用，数量通常与master数量一直，需要https或http协议通信，有两个端口一个给客户端提供服务，一个给内部通信服务
• 关于证书：etcd内部通信需要一套点对点证书来配置https、与自己的客户端（APIserver）通信需要证书和CA，APIserver与客户端通信需要一套证书和CA、和node之上的两个组件通讯分别各需要一套独立的证书和CA，一共需要5组CA来进行互相认证

node核心组件

• kubelet：执行schedule下发的任务，与APIserver交互
• Docker：容器引擎，最终产生容器的服务
• keeplive：确保pod处于健康
• controller：控制器会在node节点上一直looppod，如果一旦出现pod不符合客户预期，控制器会保证该pod恢复正常或重建，控制pod的controller只是众多控制器中的一种
• kube-proxy：负责与APIserver交互，而APIserver上会记录所有pod变化的信息，当信息改变时会由APIserver发出一个通知事件，会告知给所有相关的组件，这时kub-proxy就可以动态管理service
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dLEAYan9-1624627825373)(https://i.loli.net/2020/02/27/JFHP7XWd95jYwxS.png)]

pod的核心概念

• pod是kubernetes中最小的逻辑单位用来存放容器
• 虽然pod中可以存放多个容器，但除非容器与容器存在紧密高耦合度，否则不会这么做
• 如果一个pod中存在多个容器，这些容器共享一个网络名称空间（PIC、NET和UTS）与存储卷，这些容器的关系应该是master和sidecar（主容器和边车容器）
• kubernetes中调度器、控制器的操作对象都是pod，多个容器的pod被调度到node后，pod里所有的容器只能运行在这个node上
• labselector：通过标签选择器来筛选标签，标签不止有pod可以用
• 可以使用labelselector来过滤筛选条件，使得控制器或人用来识别和管理pod等对象
• 自主式pod：自我管理的pod，如果node挂掉，pod不会被自动重建不能全局调度
• 控制器管理的pod：调度器调度到集群的某个节点并启动和管理
• 常见的控制器分类
  1. ReplicationController：用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代，而如果异常多出来的容器也会自动回收，同时还支持滚动更新与回滚操作，早期时pod控制器只有这一个
  2. ReplicaSet：新版本后加入的新的pod控制器，代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能，但不直接使用而是使用Deployment提供声明式更新
  3. Deployment：工作在ReplicaSet之上，用于管理无状态应用，支持滚动更新和回滚功能，还提供声明式配置：只需要在Deployment中描述想要的目标状态是什么，Deployment就会将Pod和ReplicaSet的实际状态改变到目标状态，也可以定义一个全新的Deployment来创建ReplicaSet或者删除已有的Deployment并创建一个新的来替换，此外它还支持二级控制器，HPA
  4. HPA：实现POD水平自动伸缩的功能，确保负载均衡
  5. StatefulSet：管理有状态的应用
  6. DaemonSet：用于确保集群中的每一个node只运行一个特定的pod副本，通常用于实现系统级后台任务。（比如ELK服务）特性：服务是无状态的，服务必须是守护进程
  7. Job：只要完成就立即退出，不需要重启或重建（如备份操作、临时操作）
  8. Cronjob：周期性任务控制，不需要持续后台运行
• service
  1. kubernetes中所有应用运行在pod里，但由于pod的特性问题使得客户端的访问变的十分困难，所以kubernetes中提供了service的中间层，service是一个iptables的Dnet规则且不会改变IP和host当客户端需要访问服务时就可以经由service代理到对应的pod，iptables规则已经更换为了ipvs（LVS）以便提高负载效率
  2. service通过探测pod的标签选择器来关联pod，同时service还具有负载功能
  3. 这个service的ip由于没有协议栈所以不能ping通，仅仅存在于规则中

AddOns

• 如dns、监控等，且都是可以运行为pod之上的

名称空间

• 不同于docker的命名空间，kubernetes的名称空间单纯的是一个管理逻辑概念，便于管理不同类型的pod，但是不能限制pod网络，所以需要网络策略的限制

kubernetes网络

• 集群中有三个网络
  1. pod网络：同一个pod内多个容器间可以靠lo接口实现互访，而各pod间的通信使用overlay network实现

overlay network

• 使用隧道网络实现，V1机器与不在同一台宿主机的V2预先设置在同一网段内，通信时由软交换机在数据包原本结构（源IP目标IP不变）的情况下，封装一个三层、四层的IPdemo（TCP、UDP）源地址为V1宿主机目标为V2宿主机
• 基于隧道实现的叠加网络，可以隧道二层和三层
• pod与service的通信：service的ip只不过是iptables规则或lvs虚拟的ip，所以通信方式实现起来只要pod将报文发给网关（通常是docker0桥）网关再根据本机规则找到service，当规则改变时则需要kube-proxy组件来更新各个node上的规则
• 最少的网络划分需要三种：节点网络、service网络（集群网络）、pod网络
• kubernetes不负责提供实现网络的方案，需要第三方插件来实现，无论是哪种第三方方案，需要至少负责两种：service和pod网络，kubernetes开放CNI（容器网络接口），只要是基于CNI开发的方案都可以被kubernetes基于pod托管在自身上，但这些pod是特殊的，它们需要和node共享网络名称空间，除此之外也可以在node上以守护进程运行
• CNI：需要两种维度，除了实现pod和service网络之外，他们还需要负责隔离和限制各个pod之间的通信，flannel是一个ovrtlay网络可以实现网络配置，而calico是一个三层隧道网络，可以支持网络配置和网络策略，甚至支持bgp协议实现直接路由通信，flannel方便配置简单，calico困难但强大所以现在有把二者结合起来的项目：canel，用flannel配置网络calico来做限制
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zjNP0hlf-1624627825375)(https://i.loli.net/2020/02/27/bDEumKTUW3Jwx6v.png)]