K8s基本概念

1. Kubernetes简介

1.1 是什么

• 基于容器技术的分布式架构方案，源自谷歌内部的大规模集群管理系统Borg

• 希腊语，领航员；抽象数据a中心的硬件基础设施，对外暴露的是巨大的资源池

1.2 用途

• 单体应用=>微服务：单机=>集群管理，应用内耦合=>不便维护=>拆解服务=>微服务架构；
• 微服务部署难点：环境需求的差异、持续交付的需求=>容器(单容器单进程模型)=>集群资源的自动化管理和大量容器应用的自动化部署
• 核心功能：集中一切资源、提高资源利用率、帮助开发聚焦核心应用（远离服务发现、扩容、基础设施）、健康检查和自我修复、自动扩容、简化部署

2. Kubernetes组件结构与基本概念

2.1 结构

• Master(主节点、控制平面、1-3台物理主机)：整个集群的控制节点，以单进程的形式运行多个组件：
  • kubernetes API server:提供HTTP Rest接口，集群内增删改查的唯一入口，集群控制的唯一入口
  • Kubernetes Controller Manager:所有资源的自动化控制中心
  • kubernetes Scheduler:资源调度器，自动化分配pod
  • etcd持久化存储服务：存储所有资源对象的数据
• Node(工作节点，一台物理主机)：运行一定的工作负载（pod)，
  • kubelet: 负责pod对应的容器的创建、启停任务；与master协作，实现集群整体的基本管理
  • kube-proxy:实现k8s service的通信与负载均衡机制的重要组件
  • 容器引擎：docker，负责容器创建和管理
• 除了上述组件的附加组件：
  • k8s dns
  • dashboard
  • Ingress控制器
  • Heapster
  • CNI插件
• 关于组件
  • 单组件多实例：工作节点的组件运行在一台机器上，master节点上的组件除了调度器和controller manager同一时间只能有一个实例起作用外，其余组件可以以单组件多实例并行运行的模式运行在多台机器上
  • 组件如何运行：除了kubelet是系统组件，其他组件作为pod运行；可以在kube-system namespace下查看

2.2 核心组件

2.2.1 K8s API server

• 集群数据唯一访问入口

• 安全：HTTPS安全传输与CA签名数字证书强制双向认证

• RBAC访问控制策略

• api层（Restful api 接口:get list watch）->访问控制（鉴权、核准访问权）->注册表层（保存所有资源对象，如何创建对象、转换资源不同版本）->etcd数据库（存储kv数据，提供watch接口以实现List Watch机制）

• 此外还有kube proxy api 接口，通过FQDN(全限定域名)转发请求到特定pod、服务，例如：curl http://master-ip:8080/api/v1/proxy/namespaces/default/pods/my-pod-name/访问对应的pod

2.2.2 Controller Manager

• 各种资源的Controller通过设置资源的期望状态、watch资源对象事件自动化管理资源对象；controller manager则负责管理这些controller

• 常见的有：replication controller\node controller\resourceQuota controller\namespace controller\service controller\endpoints controller\pv controller

2.2.3 Scheduler调度器

• 负责pod的调度：接收controller要求创建pod的信号，在node list中选取合适的node分配pod,最后由node上的kubelet实际创建管理pod

• 调度流程：

  1. 预选调度（xxx predicates预选策略选出候选节点)：内置多个预选算法，以插件形式注册在系统中；包含资源要求的相互匹配、标签选择是否满足、端口是否被占用、使用卷要求、是否容忍节点污点、是否符合亲缘性非亲缘性要求
  2. 确定最优节点 (xxx Priority优选策略计算节点积分，选取积分最高的节点)

2.2.4 kubelet

• 注册节点到master
• 管理pod：创建、停止、健康检查（探针）

2.2.5 kubernetes Service Proxy

• 确保对服务ip和端口的某个连接最终会到达某个pod，同时负责负载均衡
• 功能：
  • 起初，kube proxy是真实的tcp/udp代理:pod用cluster IP访问某个服务->流量被本机的iptables转发到本机的kube-proxy->kube-proxy建立到后端pod的tcp/udp连接
  • 1.2版本后，kube-proxy只负责监听service\endpoints的变更信息，更新iptables，流量则通过iptables的nat机制直接路由到目标pod；相比前一个方式，iptables的转发操作不需要经过kube-proxy,效率更高
  • 进一步，iptables规则膨胀后效率降低，目前使用第三种方式，使用IPVS（IP virtual Server)+ipset，IPVS同样基于内核的netfilter（提供网络协议栈上的操作挂载点，在各个阶段放置hook函数，处理、转发、丢弃流量数据）实现，但是ipVS专门用于高性能负载均衡，并且使用hash表，易于扩张。ipset是iptables的扩展（iptables是线性结构，ipset具有索引）

2.3 基本概念

• Master:集群控制节点
• Node：工作节点
• Pod：工作负载的基本单元
  • pod内有一个或者多个业务相关的容器
  • 结构上，有一个根容器pause容器；业务容器共享pause容器的ip\挂接的卷资源，pause容器的状态与业务容器无关，代表了整个pod的状态（某个具体业务容器的死亡，不能影响整个pod的状态判断，因而采用此结构；所有资源基于pause容器，简化了共享资源时发生的容器通信过程）。
  • pod分为静态和动态，静态pod数据不存放在master上，而是放在node上的具体文件中，只存在此node上，无法被调度
  • pod中一个容器死亡会重启整个pod；所在的node死亡则重新调度到别的node
• Label:标签，一组键值对，可以标记版本、环境、架构、分区、质量管控、开发阶段；资源对象之间可以通过标签选择器进行相互匹配
• Replication Controller: rc，定义了一个期望场景：
  • pod期待的副本数量
  • 筛选pod的标签
  • 创建、恢复pod的pod template
  • 可以通过命令进行pod的滚动升级。
  • 已废弃，继任者：replicaSet\depeloyment，rc的命令基本使用于rs,rs标签选择功能更丰富，而deplyment则是更高一级的资源，隐藏管理rs的细节，提供自动化的pod创建、删除、更新的机制
• deplyment
• horizontal pod autoscaler:hpa,pod横向自动扩容，追踪分析rc控制的pod的负载情况，确定是否调整副本数量。
  • 指标：cpu平均利用率(已使用/request)、自定义的度量指标（tps,qps)
• StatefulSet:rc，rs,deployment，daemonset、job都是面向无状态的，statefulset是有状态的
  • 每个pod都有稳定、唯一的网络标识，例如ss-0,ss-1
  • pod的启停顺序受控，操作第n个pod时，前n-1个必然已经是运行且ready的状态
  • pod采用持久化存储，删除pod不会删除相关的存储卷（为了数据安全）
  • 需要与headless service配合使用，访问其中的pod需要使用唯一的dns域名
• service:服务入口，
  • 通过endpoint访问后端的pod
  • 服务发现：
    • 内部：唯一的cluster IP和service name,通过dns服务访问
    • 外部：NodePort、LB
• job：批处理任务，处理work item
  • job控制的容器短暂运行，仅运行一次，失败后不重启====>cronJob，定时启动
  • 可以多实例并行处理
• namespace:资源隔离，资源可见行
• annotation:注解，kv对，通常可以记辅助信息
• 存储\数据、配置相关：
  • Volume:卷，emtpyDir gitrepo h