《k8s权威指南》读书笔记-核心原理篇

看完本章能掌握的知识

• k8s基本架构图
• k8s重要组件的功能和原理
• k8s各个组件之间如何交互
• k8s网络模型
• k8s网络解决了docker网络的哪些局限性

一. 架构图回顾

• apiServer：资源统一入口和管理
• etcd：资源存储
• controller-manager：状态控制
• scheduler：调度
• kubelet：容器生命周期管理

二. 核心组件原理

1. APIServer

1.1 功能和作用

• 整个系统的数据总线和数据中心，负责各模块通讯
• 提供各类资源对象（pod，service等）的增、删、改、查等Restful接口
• 集群内各个功能模块之间数据交互和通信的中心枢纽
• 集群的API入口
• 资源配额入口
• 提供安全机制

1.2 存在形式

• 运行在master节点上的一个叫 kube-apiserver 的进程提供服务
• 暴露的端口：http-8080，https-6443

1.3 如何交互

• 通过kubectl命令行工具
• 通过curl命令访问
• 通过编程调用

apiserver在k8s中也是一个Service对象，名字叫做kubernetes, 通过kubectl get svc命令可以查看

1.4 工作原理

• 作为集群的核心，负责各功能模块之间的通讯
• 各功能模块通过ApiServer将信息写入Etcd
• 获取数据时，通过ApiServer提供的Restful接口实现

为了缓解集群访问压力，各模块都使用缓存，定期从ApiServer获取资源信息，保存到本地

2. Controller-Manager

2.1 功能和作用

• 集群内部的管理控制中心
• 负责集群内资源对象的管理，比如：pod，service，node，namespace
• 内部包含各种Controller，每种Controller负责一种具体的控制流程

2.2 常用的控制器

2.3 ReplicationController

• 确保集群中Pod副本一直保持预设状态
• 确保集群中有正确数量的副本（spec.replicas)
• 通过修改spec.replicas实现扩容和缩容
• 通过修改pod模板实现系统滚动升级

2.4 NodeController

• 作用：通过apiserver实时获取node相关信息，实现管理和监控Node的功能
• 监控、管理功能举例：
  • 设置节点状态信息：Ready、Not Ready、UnKnown
  • 长时间未收到kubelet的心跳信息则删除etcd中的存储信息

2.5 ResourceQuotaController

• 作用：听资源配额管理，确保资源占用不会超过系统物理资源
• 管理维度包括：
  • 容器级别：对CPU和Memory进行限制
  • Pod级别：对pod内所有容器的可用资源进行限制
  • Namespace级别：
    • pod数量
    • service数量
    • secret数量
    • pv数量

2.6 NamespaceController

• 作用：定时通过Apiserver获取保存在etcd中的namespace，并控制namespace的创建、删除等操作

2.7 Endpoints Controller

什么是endpoints？ 一个service对应的所有pod的访问地址

• 作用：负责生成和维护所有的endpoint对象，供给kube-proxy做负载均衡

2.8 Service Controller

• 作用：k8s与外部云平台之间的接口控制器，监听service的变化，确保正确的loadbalance被创建

3. Scheduler

3.1 概述

• 作用：将待调度的pod按照调度算法绑定到合适的Node上

3.2 默认调度流程

• 预选调度：遍历所有节点，选出符合要求的候选节点
• 确定最优节点：基于上一步，采用优选策略，计算出候选节点积分，最高分为分配的节点

3.3 预选策略

• 默认的预选策略包括5个维度的筛选，只有都通过了才作为候选节点
• 预选策略说明：
  • NoDiskConfilct：Volume相关冲突检测
  • PodFitsResources：资源是否满足的检测
  • PodSelectorMatches：pod标签选择器的检测
  • PodFitsHost：是否指定被调度到特定Node的检测
  • CheckNodeLabelPresense：判断label设定备选节点时，是否选择备选节点

3.4 优选策略

• LeastRequestedPriority：选出资源消耗最小的节点
• CalcuateNodeLabelPriority：通过调用用户注册的策略计算
• BalancedResourceAllocation：选出各项资源使用率最均衡的节点

4. Kubelet

4.1 概述

• 每个Node节点上都会启动一个kubelet服务进程
• 用于处理Master节点下发到该节点的任务，管理pod及pod中的容器

4.2 kubelet与ApiServer交互原理

• kubelet定期调用ApiServer的接口，汇报自身状态。ApiServer收到信息后将状态信息更新到etcd
• kubelet通过监听ApiServer的watch接口监听pod信息，如果监听到pod信息变更，会在本机做相应的操作

4.3 Pod管理

kublet通过ApiServer监听pod的变化：

• 如果发现有新的绑定到该Node的pod，则创建pod
  • 创建pod的数据目录
  • 从ApiServer获取pod信息
  • 为pod挂载volume
  • 下载pod的secret
  • 检查运行在节点中的pod，并删除无效的
  • 为pod创建pasue容器
  • 下载镜像，启动业务容器
• 如果发现有删除该Node的pod，则删除pod

4.4 容器健康检查

pod通过两类探针检查容器的监控状况

• LivenessProbe：判断容器是否健康，定期调用
• ReadnessProbe：判断容器是否启动完成

4.5 资源监控

• k8s提供基本的监控平台，由Heapster项目提供
• Heapster作为pod运行在k8s中
• Heapster通过kublet发现集群信息，并查看资源状况
• kubelet通过cAdvisor获取节点和容器的数据，并推送到可配置的后端
• cAdvisor采集cpu，文件，内存等指标信息

5. Kube-Porxy

5.1 概述

• kube-proxy运行在每个Node节点上
• 作为Service的代理和负载均衡器
• 核心功能是将Service的请求转发到后端多个pod实例
• 默认负载均衡策略是轮询

5.2 实现细节

• kube-proxy检查和监听APIServer中Service与Endpoint的变化
• kube-proxy为每个service都建立服务代理对象
• 服务代理对象是kube-proxy的数据结构，内部包含SocketServer，用来接收请求
• kube-proxy内部也创建一个负载均衡器LoadBalance
• LoadBalance保存service到endpoint的动态转发路由表

三. 网络原理

1. k8s网络模型

1.1 k8s网络模型的原则：

• 每个pod都拥有唯一个独立的ip地址，称Ip-Per-Pod模型
• 所有pod都在一个可连通的网络环境中
• 不管是否在同一个node，都可以通过ip直接通讯
• pod被看作一台独立的物理机或虚拟机

目前原生docker和kubernetes还不能打通容器与容器的通讯，以支持该模型，必须依靠第三方网络插件实现，比如：flannel

1.2 设计这个原则的原因：

• 用户不需要额外考虑如何建立pod之间的连接
• 用户不需要考虑将容器端口映射到主机端口的问题
• 可以兼容过去跑在宿主机和KVM的应用

1.3 Ip-Per-Pod与Docker端口映射的区别

• docker：端口映射到宿主机会引入端口管理的复杂性
• docker：最终被访问的ip和端口，与提供的不一致，引起配置的复杂性

2. docker网络基础

docker技术依赖于linux内核虚拟化技术的发展，对linux内核特性有很强依赖。docker用到的linux技术包括：

• network namespace
• veth设备对
• iptables、netfliter
• 网桥
• 路由

2.1 netork namespace

• 为了支持网络协议栈多个实例，linux在网络栈中引入了命名空间
• 处于不同命名空间的网络栈是彼此隔离，无法通信的
• 为了隔离协议栈，需要纳入命名空间的元素有：
  • 进程
  • 套接字
  • 网络设备
• 实现核心：
  • 将全局变量变为net namespace的成员
  • 函数都加入namespace的参数

2.2 veth设备对

• veth可以将两个命名空间连通，实现通信
• veth设备成对出现，像一根管子，连通两端

2.3 网桥

• 网桥将liunx不同的端口连接起来，实现多对多通信
• 网桥解析收到的报文，读取mac地址，决定转发的端口
• 网桥的实现：
  • 通过一个虚拟的网桥设备实现桥接
  • 虚拟设备可以绑定多个以太网设备
  • 虚拟网桥充当代理的角色

2.4 iptables/netfilter

• linux提供一套机制对网络协议栈中关心的数据进行操作
• 实现：通过回调函数的挂载点，挂接钩子函数对数据进行过滤、修改、丢弃等操作。挂节点技术叫iptables和netfilter
• netfilter工作在内核模式，执行各种挂接规则
• iptables工作在用户模式的进程，协助维护netfilter规则表

2.5 路由

• ip层处理数据或转发时，会使用路由表决定发往哪里
• 路由功能由ip层维护的路由表实现
• 路由表格式：
  • 目的ip地址：主机地址或网络地址
  • 下一个路由器的ip地址
  • 标志：下一个路由器是真实路由还是直连端口、目的ip是主机地址还是网络地址等
  • 网络接口规范：与报文一起转发
• 路由查看：ip route list

3. Docker的网桥实现

标准docker支持四种网络模式：

• host模式
• container模式
• none模式
• bridge模式，默认模式

3.1 docker的Bridge网桥模型

• docker第一次启动时，会创建虚拟网桥docker0
• 为docker0分配一个子网
• docker创建每个容器时，会创建veth设备对，一端关联到网桥上，另一端使用linux的网络命名空间技术连接到容器内，并给容器内eth0设备分配一个ip地址

docker网络模型

3.2 Docker网络的局限性

• Docker网络模型没有考虑到多主机互联的网络解决方案，崇尚简单为美
• 同一机器内的容器之间可以直接通讯，但是不同机器直接容器无法通讯
• 为了跨节点通讯，必须在主机的地址上分配端口，通过端口路由或代理到容器
• 分配和管理容器特别困难，特别是水平扩展时

4. K8s的网络实现

k8s网络实现

4.1 容器与容器的通讯

• 同一个容器的pod直接共享同一个linux协议栈
• 就像在同一台机器上，可通过localhost访问
• 可类比一个物理机上不同应用程序的情况

4.2 pod与pod的通讯

同一Node内的pod之间通讯

• 同一Node内的pod都是通过veth连接在同一个docker0网桥上，地址段相同，所以可以直接通讯

不同Node的pod之间通讯

• docker0网段与宿主机不在同一个网段，所以不同pod之间的pod不能直接通讯
• 不同node之间通讯只能通过宿主机物理网卡
• 前面说过k8s网络模型需要不同的pod之间能通讯，所以ip不能重复，这就要求k8s部署时要规划好docker0的网段
• 同时，要记录每个pod的ip地址挂在哪个具体的node上
• 为了达到这个目的，有很多开源软件增强了docker和k8s的网络

5. 开源网络组件

5.1 Flannel

实现的功能

• 协助k8s给每个Node上的docker容器分配互不冲突的ip地址
• 能在这些ip地址之间建立覆盖网络（Overlay Network），将数据传递到目标容器

底层原理

• Flannel创建名为flannel0的网桥
• flannel0网桥一端连接docker0网桥，另一端连接flanneld进程
• flanneld进程一端连接etcd，利用etcd管理分配的ip地址资源，同时监控pod地址，建立pod节点路由表
• flanneld进程一端连接docker0和物理网络，配合路由表，完成数据包投递，完成pod之间通讯

缺点

• 引入多个网络组件，带来网络时延和损耗
• 默认使用udp作为底层传输协议，具有不可靠性

5.2 其他网络组件

• Open vSwitch
• Calico