GitOps——像代码同样管理Istio配置

时间 2019-11-06

标签 gitops 代码同样管理 istio 配置繁體版

原文原文链接

GitOps——像代码同样管理Istio配置

本文译自Weaveworks 官方博客：
- https://www.weave.works/blog/gitops-for-istio-manage-istio-config-like-code
本文来源，https://mp.weixin.qq.com/s/Zt8BjW4GhR89jhprG8hD8A
本文地址，http://www.javashuo.com/article/p-hwovwrlo-cr.html

在今年的哥本哈根 Kubecon 大会上，Weaveworks 的 CEO Alexis Richardson 与 Varun Talwar（来自一家隐形创业公司）谈到了GitOps工做流程和Istio。会后Weaveworks的Stefan Prodan进行的演示，介绍如何使用 GitOps上线和管理Istio的金丝雀部署。git

会谈和演示中解释了：github

什么是 GitOps？为何须要它？
Istio 和 GitOps 的最佳实践是如何管理在其上运行的应用程序的。
如何使用 GitOps 工做流程和 Istio 进行金丝雀部署。

什么是GitOps？

GitOps 是实现持续交付的一种方式。“GitOps 使用 Git 做为声明式基础架构和应用程序的真实来源” Alexis Richardson 说。安全

当对 Git 进行更改时，自动化交付管道会上线对基础架构的更改。可是这个想法还能够更进一步——使用工具来比较实际的生产状态和源代码控制中描述的状态，而后告诉你何时集群的状态跟描述的不符。服务器

Git 启用声明式工具

经过使用 Git 这样的声明式工具能够对整套配置文件作版本控制。经过将 Git 做为惟一的配置来源，能够很方便的复制整套基础架构，从而将系统的平均恢复时间从几小时缩短到几分钟。架构

GitOps 赋能开发人员拥抱运维

Weave Cloud 的 GitOps 核心机制在于 CI/CD 工具，其关键是支持 Git 集群同步的持续部署（CD）和发布管理。Weave Cloud 部署专为版本控制系统和声明式应用程序堆栈而设计。以往开发人员都是使用 Git 管理代码和提交 PR（Pull Request），如今他们也可使用 Git 来加速和简化 Kubernetes 和 Istio 等其余声明式技术的运维工做。负载均衡

GitOps 的三个核心原则

根据 Alexis 的说法，下面描述的是为什么 GitOps 既是 Kubernetes 又是云原生核心的缘由：运维

1. GitOps 的核心是声明式配置微服务

经过使用 Git 做为实体源，并使用 Kubernetes 作滚动更新，能够观察集群并将其与指望的状态进行比较。经过将声明性配置视为代码，它容许您经过在未成功时从新应用更改来强制收敛。工具

2. 不该该直接使用 Kubectl性能

根据通常规则来看，将代码通过 CI 直接 push 到生产并非个好主意。许多人经过 CI 工具驱动部署，可是当你这样作的时候你可能不得不作一个访问生产的东西。

3. 使用 operator 模式

经过 operator 模式，集群将始终与 Git 中签入的内容保持同步。Weave Flux 是开源的，它是使用 Istio 演示下面的金丝雀部署的基础，您可使用 operator 管理集群中的更改。

不管是开发流程仍是生产流程，仍是从预发到合并到生产，operator 都会将更改 pull 到集群中，即便是有多个更改也能以原子的方式部署。

Istio 的 GitOps 工做流程

接下来，Varun Talwar 谈到了 Istio 是什么以及如何使用 GitOps 工做流管理应用程序。

Istio 是一年前发布的服务网格。它是一个专用的基础设施层，用于为微服务架构中的全部服务间交互提供服务。Istio 中的全部操做都是经过声明式配置文件驱动的。也就是说像 Istio 这样的服务网格可让开发人员在 Git 中像管理代码同样彻底的管理服务行为。

借助 Git 工做流程，开发人员能够对 Istio 中的任何内容进行建模，包括服务行为及其交互，如超时、断路器、流量路由、负载均衡及 A/B 测试和金丝雀发布等。

跨团队的多组配置

Istio 有四个普遍的领域应用，都是经过声明式配置驱动的：

流量管理：与管理入口和服务流量有关。
可观察性：监控、流量延迟、QPS、错误率等。
安全性：全部服务间调用的认证与受权。
性能：包括重试超时、故障注入和断路等。

由于全部这些领域均可以跨越组织内的不一样团队，因此这使得在 Istio 上管理应用程序尤为具备挑战性。

这些配置驱动的不少设置是跨团队的。例如，有的团队想用 Zipkin 进行跟踪，而另外一个团队可能想用 Jaeger。这些决策能够针对某一项服务进行，也能够跨服务进行。当决策跨越团队时，审批工做流程将变得更加复杂，并不老是原子性的。金丝雀发布不是原子的一次性事情。

经过 GitOps 工做流程在 Istio 上作金丝雀部署

Stefan Prodan 向咱们展现了如何使用带有 Weave Flux 和 Prometheus 的 GitOps 工做流程在 Istio 中作一次金丝雀发布——您能够在 Weave Cloud 中使用这些工具以及金丝雀部署和可观察性。

简而言之，当您想要用一部分用户测试某些新功能时，会使用金丝雀部署或发布。传统上，您可能拥有两台几乎彻底相同的服务器：一台用于全部用户，另外一台用于将新功能部署到某一组用户。

但经过使用 GitOps 工做流程，您能够经过 Git 控制您的金丝雀，而不是设置两个独立的服务器。当出现问题时，能够回滚到旧版本，而且能够在金丝雀部署分支上进行迭代，并继续发布，直到知足预期为止。

在 Weave Cloud 中，Git 控制的金丝雀发布具备彻底可观察性

经过流水线推送变动，您能够向用户发送部分必定比例的流量。使用 Weave Cloud，您能够在仪表板中观察金丝雀是否按预期工做。若是有问题能够继续修改，而后推出下一个版本，对其进行标记后经过同一流水线部署。这就是 GitOps 工做流程帮助您管理的迭代过程。

总结

Alexis Richardson 给了咱们关于 GitOps 的概述，以及为何您须要在管理运行在 Kubernetes 和 Istio 上的应用程序时考虑这种方法。而后 Varun Talwar 谈到了 Istio 是什么以及如何使用 GitOps 工做流程来管理应用程序。最后，Stefan Prodan 向咱们展现了一个特殊用例，其中非原子工做流程（如金丝雀发布）也能够经过像 Istio 这样的服务网格上的 GitOps 进行管理。

查看演讲全文及视频，请访问：https://youtu.be/VkKMf23ZokY
想要投稿，参与到 Service Mesh 相关资料的翻译活动中来，请访问 https://servicemesher.github.io/blog/gitops-for-istio-manage-istio-config-like-code/