Istio

【以下为分享实录，有删节】 测试环境管理之困与阿里巴巴的解决之道 在云原生时代下，软件的迭代速度越来越快，对测试的要求也越来越高，很多开发者开始使用Kubernetes来管理测试环境。在这个过程中，开发者会遇到很多困难，其中最主要的两个问题是：一、本地环境与Kubernetes集群网络不通问题；二、共用测试环境时，相互干扰的问题。 在阿里巴巴内部，我们主要通过扁平的内网IP和项目环境两个机制来解决以上痛点。扁平的内网IP主要是基于CNI(Conteinre Network Interface) 机制改造Kubernetes的IP逻辑实现的，可以使集群中的每个Pod分配到的IP与本地机器分配到的IP处于一个大的网络环境下，这样就可以解决本地环境和集群之间互通的问题。项目环境是基于RPC、消息中间件的虚拟环境，从表面上看，每个项目环境都是一套独立完整的测试环境，由一系列服务组成集群，而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。这样操作的好处是，第一不会占用大量的开发资源；第二，不会影响公共基础环境的稳定性。 阿里巴巴的这种测试环境带来的测试体验非常爽，本地与集群双向互通，每个子项目都可以独占一个“项目环境”，彼此不会干扰。但是这种测试环境管理方式实施起来比较复杂，只适合大型的集团公司，我们希望将这种测试体验以

作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利！ 在服务网格技术使用之前，为了更快更灵活地进行业务创新, 我们常常会把现有应用进行现代化改造, 把单体应用程序分拆为分布式的微服务架构。通常来说, 在微服务架构模式的变迁过程中, 最初都是面向代码库的模式。 对这些微服务治理的实现, 往往是以代码库的方式把这些服务治理的逻辑构建在应用程序本身中，这些代码库中包括了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等这样的一些功能。这些代码库随着功能的不断增强, 版本也随之变更，因为版本不同导致的冲突问题处处可见。此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。由此可见, 随着应用的增长和团队数量的增加，跨服务一致地使用这些服务治理功能会变得非常复杂。 服务治理的能力 Sidecar 化 通过把这些服务治理的能力 Sidecar 化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些 Sidecar 能力不需要依赖于某种特定技术框架。这就是我们常说的面向 Sidecar proxy 的架构模式。 随着这些 Sidecar 代理功能的增强，原本需要在代码库中实现的服务治理功能被抽象化为一个个通用组件, 并被逐渐地下沉到代理中。这些服务治理能力的标准化、统一化

在 Kubernetes 中有几种不同的方式发布应用，所以为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了。 选择正确的部署策略是要依赖于我们的业务需求的，下面我们列出了一些可能会使用到的策略： 重建(recreate)：停止旧版本部署新版本 滚动更新(rolling-update)：一个接一个地以滚动更新方式发布新版本 蓝绿(blue/green)：新版本与旧版本一起存在，然后切换流量 金丝雀(canary)：将新版本面向一部分用户发布，然后继续全量发布 A/B测(a/b testing)：以精确的方式（HTTP 头、cookie、权重等）向部分用户发布新版本。 A/B测 实际上是一种基于数据统计做出业务决策的技术。在 Kubernetes 中并不原生支持，需要额外的一些高级组件来完成改设置（比如Istio、Linkerd、Traefik、或者自定义 Nginx/Haproxy 等）。 你可以在 Kubernetes 集群上来对上面的这些策略进行测试，下面的仓库中有需要使用到的资源清单： https://github.com/ContainerSolutions/k8s-deployment-strategies 接下来我们来介绍下每种策略，看看在什么场景下面适合哪种策略。 重建(Recreate) - 最好在开发环境 策略定义为 Recreate 的

简介： 在正常生产环境中使用k8s部署业务后能正常运行还不够，我们需要很多附加的东西来满足日常的需求。比如日志、监控、告警等。这一篇给大家分享一下我们生产环境中的日志集中解决方案。当然不敢说是最好的，分享出来供大家参考。 在正常环境中有几类日志我们比较关心： 1、k8s中的ingress日志。比如traefik，里面记录的从公网域名访问进来的访问记录，类似nginx的access.log 2、istio中envoy边车日志。如果启用了istio那么这个日志也是需要的，每次程序被调用时都会有一个记录。 3、k8s中的事件日志。里面就有容器健康检查失败重新部署，或者pod新建、删除等事件。kubectl describe pods中的Events:内容 4、业务程序运行时产生的业务日志。比如java中常用的log4j套件输出的日志和kubectl logs命令查看的日志。这个和输出方式有关。 实现方式 这里日志收集的方式是采用elk模式，如果大家感兴趣还有loki的模式。当然这次分享是基于elk的。首先要部署的还是es集群，这里我们使用的是虚拟机部署方式非容器化。理由es是公共的组件可以对接所有的产品业务线，单独拿出来部署可以给别的产品线输出集中化日志存储方案。平时维护量还是比较少的，当然我们的es集群每15分钟大概800万条记录规模并不是特别大， 不过以后出现瓶颈横向扩容也不是问题

作者：gc(at)sysin.org，主页： www.sysin.org 请访问原文发布链接：< https://sysin.org/article/kind/>，查看最新版 。 是否没有足够的机器运行 Kubernetes 测试环境，个人电脑配置不高的话，运行多个节点的虚拟化有点力不从心，国内公有云主机一般不支持嵌套虚拟化，一套 3M+3N 的群集环境成本太高。VMware Fusion 12.0 发布，将 Kind 带入了我们的视野，这是 Google 官方的一个工具，可能是在单机运行 Kubernetes 群集的最佳方案。笔者在一台 1C 2G 的公有云虚机上运行 Kind，也不会因为计算资源有限而无法完成。 1. 简介 kind 是 Kubernetes in Docker 的简写，是一个使用 Docker 容器作为 Nodes，在本地创建和运行 Kubernetes 群集的工具。适用于在本机创建 Kubernetes 群集环境进行开发和测试。 官网：< https://kind.sigs.k8s.io/> ; kind 由以下组件构成: Go packages implementing cluster creation , image build , etc. A command line interface ( kind ) built on these

张海东， ‍多点生活（成都）云原生开发工程师。 本篇主要介绍 Pilot 源码中的 ServiceEntryStore 及其推送 xDS 的流程。 本文为 Istio Pilot 源码分析系列的第二篇文章。 Istio Pilot 源码分析（一） 了解了 Pilot 源码的基本结构和启动流程之后，我们可以深入探索 Pilot 究竟是怎么下发 xDS 协议的，以及协议的生成逻辑。相信大家都会有这些疑问：控制面与数据面详细的交互过程是什么？到底什么时候才会增量推送？增量推送判断的逻辑是什么？非 Kubernetes 原生的服务（如存在于虚拟机的服务、 Dubbo 服务等）到底是怎么注册并且经过一系列转化下发至数据面的？ 带着这些问题，开始我们今天对 Pilot 的探索。 注：本文基于 istio release-1.7 分支分析，其他版本的代码结构会有所不同。 ServiceEntryStore 在多点落地 ServiceMesh 的过程中，大量的用到了 ServiceEntry ，每一个 Dubbo 服务都会映射一个 ServiceEntry 创建在 Kubernetes 里。 ServiceEntry 的作用就是将集群外部的服务注册到 Pilot 中，再统一由 ServiceController 进行管理。相应的，管理外部服务实例的对象为 WorkloadEntry ，

系列文章: 总目录索引： 九析带你轻松完爆 Knative 系列教程 目录 1 前言 2 邀约 3 Knative 简介 4 Knative Serving 架构 4.1 Configuration 对象 4.2 Route 对象 4.3 Service 对象 4.4 Revision 对象 4.5 Knative serving 各组件之间关系 1 前言 如果你对博客有任何疑问，请告诉我。 2 邀约 你可以从 b 站搜索 “九析”，获取免费的、更生动的视频资料： 3 Knative 简介 上小节中介绍 Knative 0.17.0 版本中主要组件有 Serving 和 Event。这节简要介绍一下 Serving 组件。 Serving 组件是让应用运行起来并提供服务，其中包括： 自动启动和销毁容器 自动生成网络访问的 service、ingress 对象（这些原来需要运维编写相关 Yaml 文件） 监控应用的请求，根据请求自动进行扩缩容（这些原来需要运维指定 K8S HPA） 使用 k8s 管理应用是一件比较辛苦的事情，尽管 k8s 针对容器编排已经非常方便，但是仍然会有很多手工、重复性工作。比如，需要根据源码创建镜像（无论是手动编写 Dockerfile 还是通过工具创建流水线）、创建 deployment 对象、创建 service 对象、创建 ingress 对象

在当今日益复杂和快速变化的环境中提供更可靠软件的分步指南 。 这篇文章基于最近一次与Cloud Native Computing Foundation合作，与OverOps工程团队的Brandon Groves和Ben Morrise合作创建的网络研讨会。 如果您认为向微服务和容器的转变是演变而不是革命，那么您来对地方了！在本文中，我们将对基于Kubernetes的应用程序领域采取务实的方法，并详细介绍一系列步骤，以确保整个管道的可靠性。 因为即使今天确保应用程序质量是过去的两倍，但我们还有很多改进方法。具体来说，在对基于Kuberenetes的应用程序进行故障排除的上下文中，我们将涉及持续可靠性的3个支柱：在CI管道中实现代码质量门，在CD管道中实现可观察性，以及创建上下文反馈循环回开发。 当今软件质量状况 首先，让我们尝试了解发生了什么变化以及为什么需要重新审视代码质量的基础。 就在最近，我们总结了年度 软件质量状况 调查，来自世界各地的开发人员提供了600多个答复。我们今年的目标是找出当今的工程团队如何解决速度与质量的难题。 好消息是，大多数调查参与者（70％）表示 质量至高无上 ，他们会优先考虑速度。不幸的是，受访者每周花费一天或更长时间来排查与代码相关的问题，其中超过50％的受访者每月至少一次遇到影响客户的问题。 尽管本次调查更广泛地关注于交付可靠软件的现实和挑战，但仍有