如何解决K8s中快速交付应用的难题，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
网站建设公司,为您提供网站建设,网站制作,网页设计及定制网站建设服务,专注于企业网站制作,高端网页制作,对成都餐厅设计等多个行业拥有丰富的网站建设经验的网站建设公司。专业网站设计,网站优化推广哪家好,专业网站推广优化,H5建站,响应式网站。
前言
软件技术更新换代很快，但我们追求的目标是一直不变的，那就是在安全稳定的前提下，增加应用的部署频率，缩短产品功能的迭代周期，这样的好处就是企业可以在更短的时间内获得产品的价值、更快地获得客户反馈和响应客户需求，从而进一步提升产品的竞争力；除此之外，企业还可以释放更多的资源投入到创新业务的研发上，创造更多的价值，这是一个良性循环的过程。
应用产品的快速迭代诚然能给我们带来各种各样的好处，但挑战也与其并存。更高频率的应用发布，意味着线上业务有不可预期故障的风险更大，除了产品上线之前在预发测试环境中充分测试验证迭代功能之外，制定最合适的应用发布策略就是另外一个非常重要的话题，因为它可以最大限度的降低业务故障的风险以及带来的损失。
云原生应用交付的关键点
我们说频繁地进行产品迭代意味着更大的故障风险，传统应用如此，云原生应用更是如此。因为云原生应用通常都是基于云的分布式部署模式，且每个应用可能是由多个功能组件互相调用来一起提供完整的服务的，每个组件都有自己独立的迭代流程和计划。在这种情况下，功能组件越多，意味着出错的概率越大。那么如何在应用交付层面对上述这些痛点做出改进，我们总结出以下几个云原生应用交付的关键点。
如何充分利用云原生架构基础设施的优势。这个优势我们可以简单总结为两点：弹性和高可用；
如何具有跨平台移植和交付的能力。基础设施底层的计算、存储、网络资源有很大的差异化，在以前，基础架构的不同是由上层应用决定的，而云原生应用的交付需要具有跨平台移植和交付的能力；
如何实现应用运维自治化。自治化不等于自动化，自动化是指触发一个流程，流程结束后能自动达到想要的一个预期结果，而自治化是指应用再高可用的运行态时，如果其中某个功能组件的某个副本出现故障，应用能自动移除故障副本并补充新的应用副本；
如何让应用变得更具有可预测性。应用的交付终态，在我们编写应用编排模板的时候就是可预测到的，如果应用的交付变得更有可预测性，那么风险也会最大程度地降低；
如何提高应用更快的平均恢复时间。如果应用有超出了应用自治的能力范畴之外的故障发生需要人工介入，那更快的平均恢复时间就意味着更低的业务损失。
Kubernetes 是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。它自身的平台能力已经满足了我们前面提到的大部分需求。Kubernetes 使用容器技术部署应用，这样的好处包括但不限于：
应用程序创建和部署更敏捷
可移植性
环境一致性
松耦合和分布式
资源隔离
高效率和高密度的资源利用
Kubernetes 还提供了应用管理、调度、监控和运维的强大能力：
服务发现和负载均衡能力
应用的自动部署和回滚能力
应用的自治修复能力
存储编排能力
密钥和配置管理能力
但 Kubernetes 它也有很多功能是不提供但允许扩展的部分，比如日志采集、监控报警等能力。下面这张图就是阿里云容器服务是在支持标准 Kubernetes 的基础上，对与用户息息相关的能力做了增强和提升后的架构大图，包括提供最大的弹性化与低廉成本的全球化接入能力，强大的安全架构支撑能力，深度整合阿里云基础资源服务的能力，并经过 双11 验证和沉淀了海量用户经验，同时支持专有、托管、无服务化、边缘和神龙裸金属等多种产品形态，我们今天后面的所有演示就是在此平台上做的。
应用交付的边界
在 Kubernetes 中应用交付的边界是什么？
从简单处入手，我们可以认为应用的交付就是它的网络服务模式，服务的的后端资源以及业务数据的持久化存储，这些资源被分别抽象成 service、deployment/pod，volume 资源等。
以一个 wordpress 应用为例，它包括两个功能组件：前端组件处理用户请求，后端组件存储数据。前端组件包括一个 frontend service 和 3 个 pod，后端组件包括一个 backend service 和一个 pod 组件，所以这个 wordpress 应用交付的资源就是 2 个 service 和总共 4 个后端 pod。这个后端的 pod 资源我们在 Kubernetes 中通过 deployment 来统一管理，service 资源相当于一个负载均衡器，把请求路由到后端 pod 上，它涉及集群内各个组件之间调用以及外部用户访问集群内服务，所以有不同的种类划分。
根据服务暴露的方式不同，可以分为以下几种：
ClusterIP
通过为 Kubernetes 的 Service 分配一个集群内部可访问的固定虚拟 IP（Cluster IP），实现集群内的访问。为最常见的方式。
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: ClusterIP # 默认的service类型，服务仅暴露为集群内部可访问
ports:
- port: 80 # 暴露给集群内部的服务端口
targetPort: 80 # 容器监听的服务端口
protocol: TCP
selector:
app: wordpress # 转发请求到有相同标签的后端pod
NodePort
NodePort 是把 service 的 port 映射到集群节点的一个端口上，如果你不指定这个端口，系统将选择一个随机端口。大多数时候我们应该让 Kubernetes 来选择端口，用户自己来选择可用端口代价太大。
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: NodePort # NodePort service类型，服务暴露一个固定的静态端口用于集群外部访问
ports:
- port: 80 # 暴露给集群内部的服务端口
targetPort: 80 # 容器监听的服务端口
protocol: TCP
nodePort: 31570 # 集群外部可以通过此端口访问服务
selector:
app: wordpress # 转发请求到有相同标签的后端pod
NodePort 的方式虽然可以把服务暴露给集群外访问，但是也有很多缺点：
所以在生产中一般不推荐这种方式，但如果你的应用对成本比较敏感又能容忍服务有不可用窗口期的话，是可以使用这种方式的。
LoadBalancer
LoadBalancer 是服务暴露到集群外或者公网上的标准方式，但它依赖 cloud provider 提供的一个负载均衡器的能力，负载均衡器会单独分配一个 ip 地址并监听后端服务的指定端口，请求的流量会通过指定的端口转发到后端对应的服务。
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: LoadBalancer # LoadBalancer service类型，一般依赖于公共云厂商供的负载均衡能力
ports:
- port: 80 # 暴露给集群内部的服务端口
targetPort: 80 # 容器监听的服务端口
protocol: TCP
selector:
app: wordpress # 转发请求到有相同标签的后端pod
Ingress
ClusterIP 服务类型仅限集群内通信，NodePort 可以实现暴露服务访问入口，但每个节点都会占用一个端口，会增加端口管理的复杂性，LoadBalancer 通常需要第三方云提供商支持，有一定的约束性。而 Ingress 这个服务类型跟我们前面的三种服务类型不一样，它实际上不是一种服务类型，而是类似一种集群服务入口的存在，它可以基于你配置的不同路径或者子域名把流量路由到对应的后端服务，更像是一个“智能路由”服务。
前面介绍了一些应用发布涉及到的资源类型，以及 service 资源类型的几种模式，那 service 如何找到对应的后端 pod 呢，这个就是标签的作用，我们可以把每个应用的 pod 和 service 都打上同样的标签，这个标签的机制就是我们后面要讲的几种应用发布策略的关键点了。
应用的发布策略
在 Kubernetes 集群中，除了根据业务需求选定服务暴露方式外，为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了。
滚动发布
第一种应用发布策略就是滚动发布，这也是比较常见的策略。它是通过逐个替换实例来逐步部署新版本的应用，直到所有实例都被替换完成为止。
如下图所示，当前我的应用提供的服务版本是 v1， 这个服务的后端有 3 个副本， 但我更新版本 v2 的时候，它是一个副本一个副本地开始替换，直到最终服务的后端全部替换成 v2 版本。
一个应用示例的编排文件如下所示：
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo
spec:
replicas: 3
selector:
matchLabels:
app: go-demo
template:
metadata:
labels:
app: go-demo
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
type: ClusterIP
$ kubectl apply -f go-demo-v1.yaml
$ kubectl get po
NAME READY STATUS RESTARTS AGE
go-demo-78bc65c564-2rhxp 1/1 Running 0 19s
go-demo-78bc65c564-574z6 1/1 Running 0 19s
go-demo-78bc65c564-sgl2s 1/1 Running 0 19s
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
...
registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
...
$ kubectl apply -f go-demo-v2.yaml
$kubectl get po -w
NAME READY STATUS RESTARTS AGE
application-demo-8594ff4967-85jsg 1/1 Running 0 3m24s
application-demo-8594ff4967-d4sv8 1/1 Terminating 0 3m22s
application-demo-8594ff4967-w6lpz 0/1 Terminating 0 3m20s
application-demo-b98d94554-4mwqd 1/1 Running 0 3s
application-demo-b98d94554-ng9wx 0/1 ContainerCreating 0 1s
application-demo-b98d94554-pmc5g 1/1 Running 0 4s
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
滚动发布优点就是它比较简单，而且不会占用太多的计算资源。缺点是：
版本在实例之间缓慢替换
这个滚动发布可能需要一定时间
无法控制流量
从应用在集群中的终态上来说，集群中要么只有版本 1 的应用后端，要么只有版本 2 的后端；如果版本 2 有缺陷，那么线上服务应用到的就是整体用户， 虽然我们有机制可以快速回滚，但涉及到整体用户使用故障的代价还是太大。
蓝绿发布
第二种就是蓝绿发布，蓝/绿发布是应用版本 1 与版本 2 的后端 pod 都部署在环境中，通过控制流量切换来决定发布哪个版本。与滚动发布相比，蓝绿发布策略下的应用终态，是可以同时存在版本 1 和版本 2 两种 pod 的，我们可以通过 service 流量的切换来决定当前服务使用哪个版本的后端。
一个应用示例的编排文件如下所示。
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 4
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 4
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v1
type: ClusterIP
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
$ while sleep 0.1; do curl http://172.19.8.137; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v2
type: ClusterIP
$ kubectl apply -f service.yaml
$ [root@iZbp13u3z7d2tqx0cs6ovqZ blue-green]# while sleep 0.1; do curl http://172.19.8.137; done
Version: v2
Version: v2
Version: v2
我们刚才说到滚动升级有一个过程需要时间，即使回滚，它也需要一定的时间才能回滚完毕，在新版本应用有缺陷的情况下，蓝绿发布的策略可以快速在 v1 和 v2 两个版本之前切流量，所以这个切换流量的时间跟滚动升级相比就缩短了很多了，但蓝绿发布的缺点跟滚动发布相同的就是这个缺陷会影响到整体用户，服务要么百分百切换到版本 2 上，要么百分百切换到版本 1 上，这是个非 0 即 100 的操作，即使蓝绿发布策略可以大大缩短故障恢复时间，但在某些场景下也是不可接受的。 而且集群环境中同时存在两个版本的 pod 副本，资源占用的话相比滚动发布是 2 倍的。
金丝雀发布（灰度发布）
第三种要介绍的发布策略是金丝雀发布，金丝雀部署是应用版本 1 和版本 2 同时部署在环境中，并且用户请求有可能会路由到版本 1 的后端，也可能会路由到版本 2 的后端，从而达到让一部分新用户访问到版本 2 的应用。 这种发布策略下，我们可以通过调整流量百分比来逐步控制应用向新的版本切换，它与蓝绿部署相比，不仅继承了蓝绿部署的优点，而且占用资源优于蓝绿部署所需要的 2 倍资源，在新版本有缺陷的情况下只影响少部分用户，把损失降到最低。
对于灰度发布的概念来说，有人认为它跟金丝雀发布讲的是一个东西，有人认为它们不同。它跟金丝雀发布的过程是相同的，但目的有所不同：
示例应用 1 如下， 这个示例中我们通过 pod 的数量来控制流量比例。
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 9
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 1
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
type: ClusterIP
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
$ while sleep 0.1; do curl http://172.19.8.248; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
另外我们可以使用 nginx ingress controller 来控制流量切换，这个方式要更精准。
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 3
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 1
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
apiVersion: v1
kind: Service
metadata:
name: go-demo-v1
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v1
type: ClusterIP
apiVersion: v1
kind: Service
metadata:
name: go-demo-v2
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v2
type: ClusterIP
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/service-weight: |
go-demo-v1: 100, go-demo-v2: 0
name: go-demo
labels:
app: go-demo
spec:
rules:
- host: go-demo.example.com
http:
paths:
- path: /
backend:
serviceName: go-demo-v1
servicePort: 80
- path: /
backend:
serviceName: go-demo-v2
servicePort: 80
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/service-weight: |
go-demo-v1: 50, go-demo-v2: 50
name: go-demo
labels:
app: go-demo
spec:
rules:
- host: go-demo.example.com
http:
paths:
- path: /
backend:
serviceName: go-demo-v1
servicePort: 80
- path: /
backend:
serviceName: go-demo-v2
servicePort: 80
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v1
Version: v1
Version: v1
Version: v2
Version: v2
Version: v1
Version: v1
Version: v2
Version: v2
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/service-weight: |
go-demo-v1: 0, go-demo-v2: 100
name: go-demo
labels:
app: go-demo
spec:
rules:
- host: go-demo.example.com
http:
paths:
- path: /
backend:
serviceName: go-demo-v1
servicePort: 80
- path: /
backend:
serviceName: go-demo-v2
servicePort: 80
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
不管是金丝雀发布还是灰度发布，缺点就是发布周期相对来说要慢很多。
在这些发布策略当中，
当你在开发测试环境中对应用做更新发布的话，用滚动发布；
在生产环境，滚动更新或者蓝绿发布在新版本已经提前测试充分的情况下可以用；
如果对新版本的应用的更新需要最大限度地控制风险，降低故障对用户的影响的话，那就使用金丝雀发布或灰度发布。
以上就是我们在 Kubernetes 当中常用的几种发布策略的介绍。
关于如何解决K8s中快速交付应用的难题问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。
新闻标题：如何解决K8s中快速交付应用的难题
本文地址：
http://cdkjz.cn/article/jgiicp.html
