3 种发布策略,解决 K8s 中快速交付应用的难题

标签: 策略 k8s 应用 | 发表时间:2020-03-12 22:56 | 作者:阿里巴巴云原生
出处:http://weekly.dockone.io

作者 | 郝树伟(流生)阿里云高级研发工程师

前言

软件技术更新换代很快,但我们追求的目标是一直不变的,那就是在安全稳定的前提下,增加应用的部署频率,缩短产品功能的迭代周期,这样的好处就是企业可以在更短的时间内获得产品的价值、更快地获得客户反馈和响应客户需求,从而进一步提升产品的竞争力;除此之外,企业还可以释放更多的资源投入到创新业务的研发上,创造更多的价值,这是一个良性循环的过程。

应用产品的快速迭代诚然能给我们带来各种各样的好处,但挑战也与其并存。更高频率的应用发布,意味着线上业务有不可预期故障的风险更大,除了产品上线之前在预发测试环境中充分测试验证迭代功能之外,制定最合适的应用发布策略就是另外一个非常重要的话题,因为它可以最大限度的降低业务故障的风险以及带来的损失。

云原生应用交付的关键点

我们说频繁地进行产品迭代意味着更大的故障风险,传统应用如此,云原生应用更是如此。因为云原生应用通常都是基于云的分布式部署模式,且每个应用可能是由多个功能组件互相调用来一起提供完整的服务的,每个组件都有自己独立的迭代流程和计划。在这种情况下,功能组件越多,意味着出错的概率越大。那么如何在应用交付层面对上述这些痛点做出改进,我们总结出以下几个云原生应用交付的关键点。


  • 如何充分利用云原生架构基础设施的优势。这个优势我们可以简单总结为两点:弹性和高可用;
  • 如何具有跨平台移植和交付的能力。基础设施底层的计算、存储、网络资源有很大的差异化,在以前,基础架构的不同是由上层应用决定的,而云原生应用的交付需要具有跨平台移植和交付的能力;
  • 如何实现应用运维自治化。自治化不等于自动化,自动化是指触发一个流程,流程结束后能自动达到想要的一个预期结果,而自治化是指应用再高可用的运行态时,如果其中某个功能组件的某个副本出现故障,应用能自动移除故障副本并补充新的应用副本;
  • 如何让应用变得更具有可预测性。应用的交付终态,在我们编写应用编排模板的时候就是可预测到的,如果应用的交付变得更有可预测性,那么风险也会最大程度地降低;
  • 如何提高应用更快的平均恢复时间。如果应用有超出了应用自治的能力范畴之外的故障发生需要人工介入,那更快的平均恢复时间就意味着更低的业务损失。


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 的方式虽然可以把服务暴露给集群外访问,但是也有很多缺点:
  • 每个端口只能是一种服务
  • 端口范围有限制,一般是 30000-32767
  • 如果节点的 IP 地址变化了的话,你需要做一些变更操作去适配


所以在生产中一般不推荐这种方式,但如果你的应用对成本比较敏感又能容忍服务有不可用窗口期的话,是可以使用这种方式的。



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 版本。



一个应用示例的编排文件如下所示:
  • go-demo-v1.yaml


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

  • 部署版本 v1


$ kubectl apply -f go-demo-v1.yaml
  • 查看 pod 运行状态


$ 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

  • 更新  go-demo-v1.yaml 为  go-demo-v2.yaml 并更新镜像 tag


...
registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
...

  • 部署版本 v2


$ kubectl apply -f go-demo-v2.yaml
  • 可以查看 pod 会被新版本 pod 逐个替换


$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

  • 访问服务会发现在应用滚动升级过程中,版本 v1 和 v2 都会被访问到,这个时间的长短取决于应用的启动速度


$ 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 流量的切换来决定当前服务使用哪个版本的后端。



一个应用示例的编排文件如下所示。
  • go-demo-v1.yaml


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

  • go-demo-v2.yaml


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

  • service.yaml


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

  • 部署以上 3 个资源


$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
  • 访问服务可以看到目前只访问到版本 1 的服务


$ while sleep 0.1; do curl http://172.19.8.137; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

  • 修改  service.yaml 的 spec.selector 下 version=v2 


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
  • 重新访问服务可以看到很快切换到了版本 2 上


$ [[email protected] 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 倍资源,在新版本有缺陷的情况下只影响少部分用户,把损失降到最低。



对于灰度发布的概念来说,有人认为它跟金丝雀发布讲的是一个东西,有人认为它们不同。它跟金丝雀发布的过程是相同的,但目的有所不同:
  • 金丝雀发布更倾向于能快速获取用户的一些反馈,比如我可能不确定我的这个新版本功能的用户体验是否能被大众很好的接受,我期望能得到线上用户的一些及时反馈,在产品侧做功能体验调整之后再迭代 v3 版本;
  • 而灰度发布则是我的产品功能已经设计并开发的很完善了,现在就是要逐步替换线上的旧版本,但是要控制发布可能带来的风险,所以要灰度发布。


示例应用 1 如下, 这个示例中我们通过 pod 的数量来控制流量比例。
  • go-demo-v1.yaml 设定副本数为 9


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

  • go-demo-v2.yaml 设定副本数为 1


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

  • service.yaml


apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
type: ClusterIP

  • 部署以上 3 个资源


$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
  • 访问服务可以看到基本上是 10% 的流量切换到版本 2 上


$ 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 来控制流量切换,这个方式要更精准。
  • go-demo-v1.yaml


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

  • go-demo-v2.yaml


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

  • service-v1.yaml


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

  • service-v2.yaml


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

  • ingress.yaml, 设置  nginx.ingress.kubernetes.io/service-weight: | go-demo-v1: 100, go-demo-v2: 0, 版本1 - 100% 流量, 版本2 - 0% 流量


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

  • 部署以上 4 个资源


$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml
  • 访问服务可以看到流量 100% 到版本 1 上


$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

  • 更新  ingress.yaml, 设置流量比为 50:50


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

  • 访问服务可以看到流量 50% 到版本 1 上, 50% 到版本 2 上


$ 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

  • 更新  ingress.yaml, 设置流量比为 0:100


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

  • 访问服务可以看到流量 100% 到版本 2 上


$ 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 当中常用的几种发布策略的介绍。



阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

相关 [策略 k8s 应用] 推荐:

3 种发布策略,解决 K8s 中快速交付应用的难题

- - DockOne.io
作者 | 郝树伟(流生)阿里云高级研发工程师. 软件技术更新换代很快,但我们追求的目标是一直不变的,那就是在安全稳定的前提下,增加应用的部署频率,缩短产品功能的迭代周期,这样的好处就是企业可以在更短的时间内获得产品的价值、更快地获得客户反馈和响应客户需求,从而进一步提升产品的竞争力;除此之外,企业还可以释放更多的资源投入到创新业务的研发上,创造更多的价值,这是一个良性循环的过程.

影响K8S Pod分配和调度策略的两大关键特性

- - DockOne.io
在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略. 基于在pod规范中所提及的资源需求,Kubernetes调度器会自动选择最合适的节点来运行pod. 但在许多实际场景下,我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配. 因此,Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑.

k8s外网如何访问业务应用之Service 池化pod

- - IT瘾-geek
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念. Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象. Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行. 只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系.

k8s docker集群搭建 - CSDN博客

- -
一、Kubernetes系列之介绍篇.     - 一次构建,到处运行. 2.什么是kubernetes.   首先,他是一个全新的基于容器技术的分布式架构领先方案. Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg). 在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性.

使用kube-proxy让外部网络访问K8S service的ClusterIP

- - zzm
kubernetes版本大于或者等于1.2时,外部网络(即非K8S集群内的网络)访问cluster IP的办法是:. 修改master的/etc/kubernetes/proxy,把KUBE_PROXY_ARGS=”“改为KUBE_PROXY_ARGS=”–proxy-mode=userspace”.

K8S的SDN容器网络解决方案及其价值

- - SegmentFault 最新的文章
编者按:关于容器网络的解决方案业界已经有较多的讨论,笔者无意继续赘述. K8S及其网络模型体现了鲜明的解耦设计思想,采用SDN技术实现K8S容器网络,并与相应的生态组件形成SDN监管控一体化解决方案,可以更好地提高整个系统的运营水平,更有效地提升企业的核心竞争力. 本文拟抛砖引玉,从K8S的网络实现入手,重点阐述SDN在容器网络中的应用价值.

构建生产就绪的K8S集群的16点清单

- - SegmentFault 最新的文章
Kubernetes是用于构建高度可扩展系统的强大工具. 结果,许多公司已经开始或正在计划使用它来协调生产服务. 不幸的是,像大多数强大的技术一样,Kubernetes也很复杂. 我们整理了以下清单,以帮助你生产环境最佳实践Kubernetes. Kubernetes提供了一种编排容器化服务的方法,因此,如果您没有按顺序实践你的容器,那么集群一开始就不会处于良好状态.

9 个技巧,解决 K8s 中的日志输出问题

- - DockOne.io
作者 | 元乙  阿里云存储服务技术专家. 导读:近年来,越来越多的同学咨询如何为 Kubernetes 构建一个日志系统,或者是来求助在此过程中遇到一系列问题如何解决,授人以鱼不如授人以渔,于是作者想把这些年积累的经验以文章的形式发出来,让看到文章的同学少走弯路. K8s 日志系列文章内容偏向落地实操以及经验分享,且内容会随着技术的迭代而不定期更新,本文为该系列文章的第 3 篇.

打造热门移动应用的八大策略

- redhobor - 36氪
开发一个移动应用很容易,想要获得足够的注意力却很困难. 抓住病毒式营销的机会就像赢得一场赌局般不易. 但开发出数以百万计下载量应用的成功者总是有的,他们是如何做到的呢. 这种可以称之为应用SEO的技巧已经被部分开发者所掌握. 不妨看看下面的八条策略,帮你开发出一个叫好又叫座的热门移动应用. 1.把握”发布后的两周”这个关键时间段.

web图像的常见应用策略与技巧

- - 腾讯ISUX – 社交用户体验设计
本文介绍一些关于响应式图像的适配应用策略,回退原理,SVG的换色技巧,雪碧图的百分比定位计算公式等相关的一些小知识点,目的在于帮助一部分同学快速的理清图像应用思路,以及一些web图像的应用技巧. 1.响应式图像的应用与回退. 特点:应用简单,上手容易,性能表现良好. 根据不同设备,不同分辨率,不同像素比使用的响应式图像,常用的有两种场景:.