深入理解pod的生命周期
服务发现
微服务架构下的高可用挑战
service对象
kube-proxy
1.深入了解Pod的生命周期
如何优雅的管理Pod的完整生命周期
Pod状态机
Pod phase
Pod Phase
Pending
Running
Succeeded
Failed
Unknown
kubectl get pods显示的状态信息是由 postatus
的 conditions和 phase计算出来的
查看pod细节
kubectl get pod Spodname-oyaml
查看pod相关事件
kubectl describe pod
Pod状态计算细节
如何确保Pod的高可用
免容器进程被终止避免POd被驱逐
设置合理的 resources. memory limits防止容器进程被 OOMKILL
设置置合理的emptydir. sizelimit讲且确保数据写入不超过 empty的限制,防止Pod被驱逐
质量保证 Guaranteed, Burstable and Besteffort
定义 Guaranteed类型的资源需求来保护你的重要Pod
认真考量Pod需要的真实需求并设置 limiti和 resource,这有利于将集群资源利用率控制在合
理范围并减少Pod被驱逐的现象
尽量避免将生产Pod设置为 Besteffort,但是对测试环境来讲, Besteffort Pod能确保大多数
应用不会因为资源不足而处于 Pending状态。
Burstable适用于大多数场景。思考:为什么?
健康检查探针
• 健康探针类型分为
• livenessProbe
• 探活，当检查失败时，意味着该应用进程已经无法正常提供服务， kubelet会终止该容器进程并按照restartPolicy决定是否重启
.readinessProbe
• 就绪状态检查，当检查失败时，意味着应用进程正在运行，但因为某些原因不能提供服务，Pod状态会被标记为NotReady
.startupProbe
• 在初始化阶段（Ready之前）进行的健康检查，通常用来避免过于频繁的监测影响应用启动
・ 探测方法包括
• ExecAction:在容器内部运行指定命令，当返回码为0时，探测结果为成功
• TCPSocketAction:由kubelet发起，通过TCP协议检查容器IP和端口，当端口可达时，探测结果为成功
• HTTPGetAction:由kubele发起，对Pod的IP和指定端口以及路径进行HTTPGet操作，当返回码为200-400之间时，探测结果为成功。
探针属性
Readinessgates
Readiness允许在 Kubernetesl自
带的 Pod Conditions之外引入自
定义的就绪条件
新引入的 readiness Gates
condition需要为True状态后,加
上内置的 Conditions,Podオ可
以为就绪状态
该状忞应该由某控制器修改
Termnating Pod的误用
Terminating Pode的经验分享
terminationgraceperiodsecondss默认时长30秒
如果不关心Pod的终止时长,那么无需采取特殊措施
如果希望快速终止应用进程,那么可采取如下方案
在 presto scriptt中主动退出进程
在主容器进程中使用特定的初始化进程
优雅的初始化进程应该
正确处理系统信号量,将信号量转发给子进程
在主进程退出之前,需要先等待并确保所有子进程退出
监控并清理孤儿子进程
https://github.com/krallin/tini
在 Kubernetes上部署应用的挑战
资源规划
每个实例需要多少计算资源
CPU/GPU?
Memory
超售需求
每个实例需要多少存储资源
大小
本地还是网盘
读写性能
Disk 10
网络需求
整个应用总体QPS和带宽
存储带来的挑战
多容器之间共享存储,最简方案是 emptydir
ptydirn需要控制 size limt,否则无限扩张的应用会撑爆主机磁盘导致主机不可用
进而导致大规模集群故障
ty Dir size limit生效以后, kubelet会定期对容器目录执行du操作,会导致些许
的性能影响
size limit达到以后,Pod会被驱逐,原Pod的日志配置等信息会消失
应用配置
传入方式
Environment Variables
Volume Mount
数据来源
Configmap
Secret
Downward API
数据应该如何保存
Node
Network Volume
Root Disk
Local Disk
empty
对象存储
hostpath
共享文件系统
Secret
rootfs (Image)
高可用部署方式
多少实例
更新策略
maxsurge
maxunavailable(需要考虑 Resourcequotal的限制)
深入理解 Podtemplatehash导致的应用的易变性
课后作业(第一部分)
现在你对 Kubernetesk的控制面板的工作机制是否有了深入的了解呢?
是否对如何构建一个优雅的云上应用有了深刻的认识,那么接下来用最近学过的知识把你之前编
写的http以优雅的方式部署起来吧,你可能需要审视之前代码是否能满足优雅上云的需求。
作业要求:编写 Kubernetes部署脚本将 nttpserveri部署到 kubernetes?集群,以下是你可以思考
的维度
优雅启动
优雅终止
资源需求和Qo5保证
日常运维需求,日志等级
配置和代码分离
2.服务发现
服务发布
需要把服务发布至集群内部或者外部,服务的不同类型
Clusterlp( Headless)
Nodeport
Loadbalancer
Externalname
证书管理和七层负载均衡的需求
需要gRPC负载均衡如何做?
DNS需求
与上下游服务的关系
服务发布的挑战
kube-dns
DNS TTLI问题
Cluster只能对内
kube- proxy支持的 iptables/ipvs规模有限
IPVS的性能和生产化问题
kube- proxy的 drifti问题
频繁的Pod变动( spec change, failover, crashloop)导致LB频繁变更
对外发布的 Service需要与企业ELB即成
不支持gRPC
不支持自定义DNS和高级路由功能
Ingress
Spec的成熟度?
其他可选方案?
跨地域部署
需要多少实例
如何控制失败域,部署在几个地区,AZ,集群?
如何进行精细的流量控制
如何做按地域的顺序更新
如何回滚
3.微服务架构下的高可用挑战
服务发现
微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,
服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问
题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现
目标服务。
同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康
检查问题。
理解网络包格式
集中式服务发现
在服务消费者和服务提供者之间有一个独立的LB
LB上有所有服务的地址映射表,通常由运维配置注册。
当服务消费方调用某个目标服务时,它向LB发起请求,由LB以某种策略(比如 Round- Robin)
做负载均衡后将请求转发到目标服务
B一般具备健康检查能力,能自动摘除不健康的服务实例
服务消费方通过DNS发现LB,运维人员为服务配置一个DNS域名,这个域名指向LB。
集中式LB方案实现简单,在LB上也容易做集中式的访问控制,这一方案目前还是
业界主流
中式LB的主要问题是单点问题,所有服务调用流量都经过LB,当服务数量和调
用量大的时候,LB容易成为瓶颈,且一旦LB发生故障对整个系统的影响是灾难性
LB在服务消费方和服务提供方之间增加了ー跳(hop),有一定性能开销
进程内LB服务发现
进程内LB方案将LB的功能以库的形式集成到服务消费方进程里头,该方案也被称为客户端负载方案。
服务注册表( Service Registry)配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到
服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态
服务消费方要访问某个服务时,它通过内置的LB组件向服务注册表查询(同时缓存并定期刷新)目标服务
地址列表,然后以某种负载均衠策略选择一个目标服务地址,最后向目标服务发起请求
这一方案对服务洼册表的可用性( Availability)要求很高,一般采用能满足高可用分布式一致的组件(例如Zookeeper, Consul,etcd等)来实现
进程内LB是一种分布式模式,LB和服务发现能力被分散到每一个服务消费者的进
程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比
较好。该方案以客户库( Client Library)的方式集成到服务调用方进程里头,如果
企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和
维护成本。
客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级
势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力
独立LB进程服务发现
针对进程内LB模式的不足而提出的一种折中方案,原理和第二种方案基本类似。
不同之处是,将LB和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多
服务要访问目标服务时,他们都通过同一主机上的独立LB进程做服务发现和负载均衡
B独立进程可以进一步与服务消费方进行解耦,以独立集群的形式提供高可用的负载均衡服务。
这种模式可以称之为真正的“软负载( Soft Load Balancing)
独立LB进程也是一种分布式方案,没有单点问题,一个LB进程挂了只影响该主机上的服务调用
服务调用方和LB之间是进程间调用,性能好
简化了服务调用方,不需要为不同语言开发客户库,LB的升级不需要服务调用方改代
不足是部署较复杂,环节多,出错调试排查问题不方便
负载均衡
系统的扩展可分为纵向(垂直)扩展和横向(水平)扩展
纵向扩展,是从单机的角度通过增加硬件处理能力,比如CPU处理能力,内存容量,磁盘等方面,实现
服务器处理能力的提升,不能满足大型分布式系统(网站),大流量,高并发,海量数据的问题
横向扩展,通过添加机器来满足大型网站服务的处理能力。比如:一台机器不能满足,则增加两台或者
多台机器,共同承担访问压力,这就是典型的集群和负载均衡架构
负载均衡的作用(解决的问题)
解决并发压力,提高应用处理性能,增加吞吐量,加强网络处理能力
是供故障转移,实现高可用
通过添加或减少服务器数量,提供网站伸缩性,扩展性
全防护,负載均衡设备上做一些过滤,黑白名单等处理
DNS负载均衡
最早的负载均衡技术,利用域名解析实现负载均衡,在DNS服务器,配置多个A记录,这些A记录
对应的服务器构成集群
DNS负载均衡
负载均衡技术概览
网络地址转换
网络地址转换( Network Address Translation,NAT)通常通过修改数据包的源地址( Source
NAT)或目标地址( estination NAT)来控制数据包的转发行为
新建TCP连接
为记录原始客户端IP地址,负载均衡功能不仅需要进行数据包的源目标地址修改,同时要记录原
始客户端IP地址,基于简单的NAT无法满足此需求,于是衍生出了基于传输层协议的负载均衡的
另一种方案-TCP/ UDP Termination方案
链路层负载均衡
在通信协议的数据链路层修改MAC地址进行负载均衡。
数据分发时,不修改P地址,指修改目标MAC地址,配置真实物理服务器集群所有机器虚拟P
和负载均衡服务器P地址一致,达到不修改数据包的源地址和目标地址,进行数据分发的目的。
实际处理服务器P和数据请求目的IP一致,不需要经过负载均衡服务器进行地址转换,可将响
应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模
式(DR模式)。
隧道技术
负载均衡中常用的隧道技术是 EIP over IP,其原理是保持原始数据包IP头不变,在IP头外层增加额
外的IP包头后转发给上游服务器
上游服务器接收P数据包,解开外层lP包头后,剩下的是原始数据包
同样的,原始数据包中的目标P地址要配置在上游服务器中,上游
处理完数据请求以后,
响应包通过网关直接返回给客户端
4.Service对象
Service对象
Service Selector
Kubernetes允许将Pod对象通过标签
( Label)进行标记,并通过 Service
elector定义基于Pod标签的过滤规则,
以便选择服务的上游应用实例
Ports
Ports属性中定义了服务的端口、协议目
标端口等信息
Endpoint对象
当 Service的 selector,不为空时, Kubernetes Endpoint
Controllers会侦听服务创建事件,创建与 Service同名的
Endpoint对象
selector能够选取的所有 Dodie都会被配置到 addresses属性
中
如果此时 selecto所对应的fitr查询不到对应的Pod,则
addresses列表为空
默认配置下,如果此时对应的Pod为 not ready?状态,则对应的
Podi只会出现在 subsets的 notreadyaddressesl属性中,这意
味若对应的Pod还没准备好提供服务,不能作为流量转发的目标。
如果设置了 Publishnotreadyadddress/为true,则无论Pod是
否就绪都会被加入 readyaddress list
Endpointslice对象
。当某个 Service对应的 backend Pod:较多时
Endpoints对象就会因保存的地址信息过多
而变得异常庞大
Pod状态的变更会引起 Endpoint的变更
Endpoint的变更会被推送至所有节点,从
而导致持续占用大量网络带宽
Endpointslice>对象,用于对Pod较多的
Endpoint进行切片,切片大小可以自定义
apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
name: example-abc
labels:
kubernetes.io/service-name: example
addressType: IPv4
ports:
- name: http
protocol: TCP
port: 80
endpoints:
- addresses:
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
topology:
kubernetes.io/hostname: node-1
topology.kubernetes.io/zone: us-west2-a
不定义 Selector的 service
用户创建了 Servicer但不定义 Selector
Endpoint Controller.不会为该 Servicel自动创建 Endpoint
用户可以手动创建 Endpoint对象,并设置任意IP地址到 Address属性
访问该服务的请求会被转发至目标地址
通过该类型服务,可以为集群外的一组 Endpoint创建服务
Servier、EndPoint和Pod的对应关系
Service 类型
• clusterIP
・Service的默认类型，服务被发布至仅集群内部可见的虚抑P地址上。
在API Server启动时，需要通过service-cluster-ip-range参数配置虚拟IP地址段，API Server中有用于分配IP地址和端口的组件，当该组件捕获Service对象并创建对象时，会从配置的虚拟IP地址段取一个有效的IP地址，分配给该Service对象。
nodeport
在API Server启动时，需要通过node-port-range参数配置nodePort的范围，同样地，API Server组件会捕获service对象并创建事件，即从配置好的nodePort范围取一个有效端口，分配给Service。
每个节点的kube-proxy会尝试在服务分配的 nodeport上建立侦听器接收请求,并转发给服务对应
• LoadBalancer
•企业数据中心一般会采购一些负载均衡器，作为外网请求进入数据中心内部的统一流量入口。
•针对不同的基础架构云平台，Kubernertes Cloud Manage提供支持不同供应商API的Service Controller。如果需要在Openstack云平台上搭建Kubernetes集群，那么只需提供一份 openstack.rc, Openstack Service Controller即可通过调用LBaaS API完成负载均衡配置。
其他类型服务
Headless Service
Headless服务是用户将 cluster显示定义为None的服务。
无头的服务意味着 Kubernetes不会为该服务分配统一入口,包括 cluster, nodeport等
Externalname Service
为一个服务创建别名
Headless?和 externalnamel服务的使用场景?我们随后讨论
Service Topology
一个网络调用的延迟受客户端和服务器所处位置的影响,两者是否在同一节点、同一机架、同
用区、同一数据中心,都会影响参与数据传输的设备数量
在分布式系统中,为保证系统的高可用,往往需要控制应用的错误域( Failure Domain),比
如通过反亲和性配置,将一个应用的多个副本部署在不同机架,甚至不同的数据中心
Kubernetes提供通用标签来标记节点所处的物理位置,如
topology. kubernetes io/zone: us-west2-a
failure-domain. beta kubernetes io/region: us-west
failure-domain. tess. io/network-device us-westo5-ra053
domain.tess. io/rack: us west02 02-314 12
kubernetes io/hostname node-1
Service Topology
Service引入了 topologykeysl属性,可以通过如下设置来控制流量
当 topologykeysi设置为[" kubernetes io/ hostname]时,调用服务的客户端所在节点上如
果有服务实例正在运行,则该实例处理请求,否则,调用失败
当 topology Keysi设置为" kubernetes.io/ hostname"," topology. kubernetes.o/zone
" topology. kubernetes.io/ region"]时,若同一节点有对应的服务实例,则请求会优先转发
至该实例。否则,顺序查找当前zone及当前 Region是否有服务实例,并将请求按顺序转发
当 topologykeysi设置为" topology. kubernetes.io/zone","*"]时,请求会被优先转发至当
前zone的服务实例。如果当前zone不存在服务实例,则请求会被转发至任意服务实例。
5.kube-proxy
kube-proxy
每台机器上都运行一个kube- proxy服务,它监听 Apl server中 service?和 endpoint的变化情
况,并通过 iptables等来为服务配置负载均衡(仅支持TCP和UDP)。
kube- proxy可以直接运行在物理机上,也可以以 static pod或者 Daemonsetl的方式运行。
kube- proxy当前支持一下几种实现
userspace:最早的负载均衡方案,它在用户空间监听一个端口,所有服务通过 iptables
转发到这个端口,然后在其内部负载均衡到实际的Pod。该方式最主要的问题是效率低,
有明显的性能瓶颈
tables:目前推荐的方案,完全以 iptables规则的方式来实现 service负载均衡。该方式
主要的问题是在服务多的时候产生太多的 Iptables规则,非增量式更新会引入一定的时
延,大规模情况下有明显的性能问题
pvs:为解決iptables模式的性能问题,V1.8新增了ipvs模式,采用增量式更新,并可以
保证 service更新期间连接保持不断开
Winuserspace:同 userspace,但仅工作在 windows上
Linux内核数据处理包：Netfilter框架
Netfilter和iptables
iptables
iptables的锚点
kube-proxy工作原理
kubernetes iptables规则
iptables示例
-A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000 -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
-A KUBE-SEP-55QZ6T7MF3AHPOOB -s 10.244.1.6/32 -m comment --comment "default/http:" -j KUBE-MARK-MASQ -A KUBE-SEP-55QZ6T7MF3AHPOOB -p tcp -m comment --comment "default/http:" -m tcp -j DNAT --to-destination 10.244.1.6:80
-A KUBE-SEP-KJZJRL2KRWMXNR3J -s 10.244.1.5/32 -m comment --comment "default/http:" -j KUBE-MARK-MASQ-A KUBE-SEP-KJZJRL2KRWMXNR3J -p tcp -m comment --comment "default/http:" -m tcp -j DNAT --to-destination 10.244.1.5:80
-A KUBE-SERVICES -d 10.101.85.234/32 -p tcp -m comment --comment "default/http: cluster IP" -m tcp --dport 80 -j KUBE-SVC-7IMAZDGB2ONQNK4Z
-A KUBE-SVC-7IMAZDGB2ONQNK4Z -m comment --comment "default/http:" -m statistic --mode random -- probability 0.50000000000 -j KUBE-SEP-KJZJRL2KRWMXNR3J
-A KUBE-SVC-7IMAZDGB2ONQNK4Z -m comment --comment "default/http:" -j KUBE-SEP-55QZ6T7MF3AHPOOB
IPVS
IPVS支持的锚点和核心函数
域名服务
Kubernetes Service通过虚拟IP地址或者节点端口为用户应用提供访问入口
然而这些IP地址和端口是动态分配的,如果用户重建一个服务,其分配的 cluster和
deport,以及 Load Balancerlpa都是会变化的,我们无法把一个可变的入口发布出去供他
人访问
Kubernetes提供了内置的域名服务,用户定义的服务会自动获得域名,而无论服务重建多少
次,只要服务名不改变,其对应的域名就不会改变
Coredns
COREDNST包含一个内存态DNS,以及与其他 controller类似的控制器
Coredns的实现原理是,控制器监听5 ervice和 Endpoint的变化并配置DNS,客户端Pod在进行
域名解析时,从 Coredns中查询服务对应的地址记录
不同类型服务的DNS记录
普通 Service
Cluster、 nodeport、 Load Balancer类型的 Servicei都拥有 API Server.分配的 Cluster
eDNS会为这些5 ervine创建FQDN格式为 Ssvcname. Namespace.Svc
clusterdomain: cluster的A记录及PTR记录,并为端口创建SRV记录
Headless Service
名思义,无头,是用户在Spec显式指定 luster为None的 Service,对于这类 Service
Apl Server.不会为其分配 luster。 Coredns为此类 Service创建多条A记录,并且目标为
每个就绪的 Podi
另外,每个Pod会拥有一个QDN格式为$ podname. 5svcname. namespace.SvC.
clusterdomain的A记录指向 Podi
Externalname Service
此类 Service用来引用一个已经存在的域名, Coredns会为该 service创建一个 Cname记录
指向目标域名
Kubernetes中的域名解析
Kubernetes Pod?有一个与DNS策略相关的属性 DNSPOLICY,默认值是 Clusterfirst
Pod启动后的/etc/ resolv.conf会被改写,所有的地址解析优先发送至 Coredns
s cat /etc/resolv con
search ns1svccluster. localsvc cluster, localcluster loca
nameserver 192.168.0.10
options dots
当Pod启动时,同- Namespace的所有 Service都会以环境变量的形式设置到容器内
影响?
关于DNS的落地实践
Kubernetes1作为企业基础架构的一部分, Kubernetes服务也需要发布到企业DNS,需要定
制企业DNS控制器
对于 Kubernetest中的服务,在企业DNS同样创建A/PTR/ SRV records(通常解
析地址是 Loadbalancer VIP)
针对 headless service,在 Podi可全局路由的前提下,按需创建 DNS records
Headless service的DNS记录,应该按需创建,否则对企业DNS冲击过大
服务在集群内通过 oredns寻址,在集群外通过企业DNS寻址,服务在集群内外有统一标识
Kubernetes中的负载均衡技术
基于L4的服务
基于 iptables/ipvs的分布式四层负載均衡技术
各种Load Balancer Provider提供与企业现有ELB的整合
kube- proxy基于 iptables rules为 Kubernetes形成全局统一的 distributed load balancer
kube- proxy是一种mesh, Internal Client无论通过podip,nodeport还是LB VIP都经由kube- proxy跳转至Pod
属于 Kubernetes core
基于L7的 Ingress
基于七层应用层,提供更多功能
TLS termination
L7 path forwarding
Url/http header rewrite
与采用7层软件紧密相关
Ingress
° Ingress
ogress是一层代理
负责根据 hostname和path将流量转发到不同的服务
上,使得一个负載均衡器用于多个后台应用
・ Kubernetes Ingress Spec是转发规则的集合
Ingress controller
确保实际状态( Actual)与期望状态( Desired)一致的 Control
Loop
Ingress Controller确保
负载均銜配置
边缘路由配置
DNS配置
Ingress
传统应用网络拓扑
问什么需要构建SLB方案
堪待解决的问题
L4集群架构
L7集群架构
数据流
跨大陆的互联网调用
互联网路径的不确定性
边缘加速方案综述
边缘加速组件
对网络路径的优化
课后作业
在你对 Kubernetes的控制面板的工作机制是否有了深入的了解呢?
是否对如何构建一个优雅的云上应用有了深刻的认识,那么接下来用最近学过的知识把你之前编
的http以优雅的方式部署起来吧,你可能需要审视之前代码是否能满足优雅上云的需求。
作业要求:编写 Kubernetes部署脚本将 nttpserveri部署到 kubernetes?集群,以下是你可以思考
优雅启动
优雅终止
资源需求和Qo5保证
探活
日常运维需求,日志等级
配置和代码分离
课后作业(第二部分)
除了将httpserver应用优雅的运行在Kubernetes.之上,我们还应如何将服务发布给对内和对外的调用方。
来尝试用 Service, Ingress将你的服务发布给集群外部的调用方吧
在第一部分的基础上提供更加完备的部署spec,包括(不限于)
Service
Ingress
可以考虑的细节
如何确保整个应用的高可用
如何通过证书保证httpservere的通讯安全
1696
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
