Kubernetes -- 应用开发视角

云原生架构

Cloud Native App

Applications adopting the principles of Microservices packaged as Containers orchestracted by Platforms running on top of Cloud infrastructure, developed using practices such as Continous Delivery and DevOps.

云演进史

Kubernetes

目标

Kubernetes本质上是为了简化微服务的开发和部署,解决微服务的公共关注点

image-20210622111530201

架构

image-20210622111821371

  1. 架构模式:Master-Slave
  2. Node可以是物理机也可以是虚拟机
  3. Master(为保证HA,Master也是多节点部署,但真正做调度决策的只有一个Master节点,因此涉及到选主
    • etcd单独部署
      • 基于KV分布式存储,底层采用Raft协议,保存Kubernetes的状态数据
    • API Server
      • 对外提供操作和获取Kubernetes集群资源的API,唯一可以操作etcd的组件 – 被Google和RedHat紧紧把控
    • Scheduler
      • Kubernetes集群的大脑,用于调度决策(如决定Pod分布在哪些Node上)
    • Controller Manager
      • Kubernetes集群状态的协调者
      • 观察集群目前的实际状态,对比etcd中的预期状态,如果不一致则进行调谐,达到最终一致(支持Self Healing
  4. Worker
    • Container Runtime
      • 下载镜像 + 运行容器
    • Pod
      • 对容器的包装
      • Kubernetes的基本调度单位
    • kubelet
      • 负责管理Worker节点上的组件,相当于一个Agent角色
      • 与Master节点上的API Server进行交互,接收指令,执行操作(如启停Pod,返回状态数据等)
      • Scheduler vs kubelet
        • Scheduler:整个Kubernetes集群的大脑
        • kubelet:每个Worker节点上的小脑
    • kube-proxy
      • 负责对Pod进行IP寻址负载均衡,实现Service和服务发现抽象的关键,底层操作iptables规则
  5. 操作Kubernetes集群的方式
    • kubectl、dashboard、sdks
  6. 网络
    • Overlay网络(内部,覆盖网络):Pod之间通信
    • Load Balander(外部)

基本概念

Cluster

Node可以是虚拟机也可以是物理机,Node可以按需添加,Kubernetes是一个超大型计算机(所有Node的总和)

image-20210622115458107

Container

Container的本质是宿主机上的一个进程

image-20210622115756179

Pod

  1. Pod(豌豆荚)是Kubernetes的基本调度单位,Pod里可以有一个或多个容器(共享Pod的文件系统网络
  2. Kubernetes没有直接调度容器的原因
    • 需要辅助容器的场景(Sidecar
    • 不与具体的容器技术绑定,考虑替换成不同的容器技术

image-20210622115919448

发布 & 服务

ReplicaSet

image-20210622122414844

Service

  1. Pod是不固定的,可能会重启,因此IP会发生变化
  2. Service屏蔽了应用的IP寻址负载均衡的细节,直接通过服务名访问服务

image-20210622122630934

Deployment

ReplicaSet是基本的发布机制,Deployment是高级的发布机制(支持金丝雀发布、蓝绿发布等)

image-20210622123059313

Rolling Update

image-20210622123429625

小结

Service是服务间相互路由寻址的概念

image-20210622123707068

ConfigMap & Secret

image-20210622124040831

DaemonSet

image-20210622124256870

PersistentVolume & PersistentVolumeClaims

image-20210622124445579

image-20210622124436167

StatefulSet

  1. StatefulSet:有状态应用
  2. ReplicaSet:无状态应用

Label & Selector

Label用于给Kubernetes资源打标签,Selector是通过Label查询定位Kubernetes资源的机制

image-20210622124847890

Namespace

Namespace是Kubernetes的逻辑隔离机制

image-20210622125127499

Probe

  1. Readiness Probe(就绪探针):判断Pod是否可以接入流量
  2. Liveness Probe(活跃探针):判断Pod是否存活

小结

概念 概念
Cluster 超大计算机抽象,由节点组成
Container 应用居住和运行在容器中
Pod Kubernetes基本调度单位
ReplicaSet 创建和管理Pod,支持无状态应用
Service 应用Pods的访问点,屏蔽IP寻址和负载均衡
Deployment 管理ReplicaSet,支持滚动等高级发布机制
ConfigMap/Secrets 应用配置,Secret敏感数据配置
DaemonSet 保证每个节点有且仅有一个Pod,常见于监控
StatefulSet 类似 ReplicaSet,但支持有状态应用
Job 运行一次就结束的任务
CronJob 周期性运行的任务
Volume 可装载磁盘文件存储
PersisentVolume/ PersistentVolumeClaims 超大磁盘存储抽象和分配机制
Label/Selector 资源打标签和定位机制
Namespace 资源逻辑隔离机制
Readiness Probe 就绪探针,流量接入Pod判断依据
Liveness Probe 存活探针,是否kill Pod的判断依据

网络

节点网络 & Pod网络

image-20210622130201306

  1. 节点网络
    • 保证Kubernetes节点之间能够正常的做IP寻址和通信
    • 节点网络空间:10.100.0.1/24
  2. Pod网络
    • Pod网络构建在节点网络之上覆盖网络),用于保证Pod之间能够正常的做IP寻址和通信
    • Pod内部有一个或多个容器,这些容器共享网络栈(类似于虚拟网卡),容器之间通过localhost进行访问
    • Pod的网络栈Pause容器创建
    • 实现Pod网络
      • 在每个节点上创建虚拟网桥(类似于虚拟交换机),并管理这些虚拟网桥的地址空间和分配
      • 修改路由器的路由规则,使得不同节点上的Pod可以通信
      • 一个节点上的Pod都会挂在对应的虚拟网桥(cbr0)上,并获得IP地址
    • Pod网络空间:10.0.0.0/14
    • Pod A(10.0.1.2)访问Pod B(10.0.2.2)
      • Pod A的veth0(10.0.1.2)将请求转发到本节点的cbr0(10.0.1.1)
      • cbr0(10.0.1.1)发现10.0.2.2不在本节点,向上转发到eth0(10.100.0.2)
      • eth0(10.100.0.2)无法解析10.0.2.2,向上转发给router(10.100.0.1)
      • router(10.100.0.1)检查路由表,发现10.0.2.2命中第二条路由规则,转发给eth0(10.100.0.3)
      • eth0(10.100.0.3)认出该请求是可以由cbr0(10.0.2.1)处理,转发给cbr0(10.0.2.1)
      • cbr0(10.0.2.1)认出该请求对应Pod B,转发给veth0(10.0.2.2)

Service网络

  1. Service:屏蔽Pod的地址变化 + 对Pod以负载均衡Service Name)的方式访问
  2. Service网络(没有具体的虚拟网络设备)是在Pod网络(有具体的虚拟网络设备)之上构建的网络

image-20210622150448796

用户空间代理模式

image-20210622153850068

  1. Kube-proxy工作在用户空间代理模式时,直接承担请求转发的职责
  2. 服务注册发现
    • Kubernetes发布一个Service,名称为service-test
      • Kubernetes为该Service分配一个Cluster IP(10.3.241.152),地址空间为10.3.240.0/20
      • 相关信息会通过API Server记录在etcd,后续Pod如果有变动,etcd中的信息也会变动
    • Worker节点的kube-proxy会监听API Server上这些Service的信息变动,并且将信息同步到netfilter
      • 告知netfilter要对相关的IP进行包过滤,并转发给kube-proxy
  3. 服务调用
    • 通过本地的DNS(DNS同样也会监听Service的变化)查询这个Service的Cluster IP(10.3.241.152)
    • 将请求转发到本地Pod的veth0(10.0.2.3),veth0通过cbr0向eth0转发,转发过程中会被netfilter截获
    • netfilter将目标地址为10.3.241.152的请求转发给kube-proxy
    • kube-proxy会依据负载均衡策略选择一个Pod(10.0.2.2),然后通过eth0向10.0.2.2发送请求
  4. 特点
    • 版本 ≤ Kubernetes 1.2
    • netfilter(内核空间)转发请求到kube-proxy(用户空间),存在开销

iptables/ipvs模式

  1. 性能更高,版本 ≥ Kubernetes 1.8
  2. kube-proxy的职责:将信息同步给netfilter

image-20210622173549083

NodePort vs LoadBalancer vs Ingress

  1. 外部网络一般可以访问到节点网络,Pod网络和Service网络属于Kubernetes的内部网络
  2. Service通过kube-proxy暴露在节点网络上
    • kube-proxy在节点上暴露一个监听转发服务,相当于在节点网络Service网络之间搭了一座

image-20210622174246300

NodePort:将Service暴露在节点网络

image-20210622175323420

Load Balancer:具有公网IP + 负载均衡 – 付费

image-20210622175511637

image-20210622175724139

小结

作用 实现
节点网络 Master/Worker节点之间网络互通 路由器、交换机、网卡
Pod网络 Pod之间互通 虚拟网卡、虚拟网桥、路由器
Service网络 屏蔽Pod地址变化 + 负载均衡 kube-proxy、netfilter、API Server、DNS
NodePort 将Service暴露在节点网络 kube-proxy、netfilter
LoadBalancer 将Service暴露在公网上 + 负载均衡 公有云LB + NodePort
Ingress 反向路由、安全、日志监控
类似于反向代理、网关
Nginx、Envoy、Traefik、Faraday

参考资料

  1. Spring Boot与Kubernetes云原生微服务实践
0%