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本质上是为了简化微服务的开发和部署,解决微服务的公共关注点
架构
- 架构模式:Master-Slave
- Node可以是物理机也可以是虚拟机
- 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)
- etcd(单独部署)
- 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规则
- Container Runtime
- 操作Kubernetes集群的方式
- kubectl、dashboard、sdks
- 网络
- Overlay网络(内部,覆盖网络):Pod之间通信
- Load Balander(外部)
基本概念
Cluster
Node可以是虚拟机也可以是物理机,Node可以按需添加,Kubernetes是一个超大型计算机(所有Node的总和)
Container
Container的本质是宿主机上的一个进程
Pod
- Pod(豌豆荚)是Kubernetes的基本调度单位,Pod里可以有一个或多个容器(共享Pod的文件系统和网络)
- Kubernetes没有直接调度容器的原因
- 需要辅助容器的场景(Sidecar)
- 不与具体的容器技术绑定,考虑替换成不同的容器技术
发布 & 服务
ReplicaSet
Service
- Pod是不固定的,可能会重启,因此IP会发生变化
- Service屏蔽了应用的IP寻址和负载均衡的细节,直接通过服务名访问服务
Deployment
ReplicaSet是基本的发布机制,Deployment是高级的发布机制(支持金丝雀发布、蓝绿发布等)
Rolling Update
小结
Service是服务间相互路由寻址的概念
ConfigMap & Secret
DaemonSet
PersistentVolume & PersistentVolumeClaims
StatefulSet
- StatefulSet:有状态应用
- ReplicaSet:无状态应用
Label & Selector
Label用于给Kubernetes资源打标签,Selector是通过Label查询定位Kubernetes资源的机制
Namespace
Namespace是Kubernetes的逻辑隔离机制
Probe
- Readiness Probe(就绪探针):判断Pod是否可以接入流量
- 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网络
- 节点网络
- 保证Kubernetes节点之间能够正常的做IP寻址和通信
- 节点网络空间:10.100.0.1/24
- 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网络
- Service:屏蔽Pod的地址变化 + 对Pod以负载均衡(Service Name)的方式访问
- Service网络(没有具体的虚拟网络设备)是在Pod网络(有具体的虚拟网络设备)之上构建的网络
用户空间代理模式
- Kube-proxy工作在用户空间代理模式时,直接承担请求转发的职责
- 服务注册发现
- 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
- Kubernetes发布一个Service,名称为service-test
- 服务调用
- 通过本地的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发送请求
- 特点
- 版本 ≤ Kubernetes 1.2
- netfilter(内核空间)转发请求到kube-proxy(用户空间),存在开销
iptables/ipvs模式
- 性能更高,版本 ≥ Kubernetes 1.8
- kube-proxy的职责:将信息同步给netfilter
NodePort vs LoadBalancer vs Ingress
- 外部网络一般可以访问到节点网络,Pod网络和Service网络属于Kubernetes的内部网络
- Service通过kube-proxy暴露在节点网络上
- kube-proxy在节点上暴露一个监听转发服务,相当于在节点网络和Service网络之间搭了一座桥
NodePort:将Service暴露在节点网络上
Load Balancer:具有公网IP + 负载均衡 – 付费
小结
作用 | 实现 | |
---|---|---|
节点网络 | 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 |
参考资料
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.