Istio

本周三晚20:30，Kubernetes Master Class在线培训第三期《Kubernetes应用商店：Harbor与Istio》即将开播，进入 http://live.vhall.com/231749318 即可免费预约注册！ 美国著名的企业生产力解决方案领先供应商Workiva，投入使用开源的企业级Kubernetes管理平台Rancher，通过无缝连接到Rancher，指数级减少了构建和部署容器及Kubernetes服务所需的时间和精力。本文将分享Workiva的需求与痛点、以及他们的经验。 Workiva是美国著名的互联数据、报告和合规解决方案的领先云提供商（纽约证券交易所上市代码 NYSE: WK）。Workiva提供直观的云平台Wdesk，帮助全球超过3000家企业实现工作方式的现代化，其中包括70％以上的财富500强(FORTUNE 500®)公司。 需求与痛点 Wdesk建立在数据管理引擎上，提供受控协作、数据连接、细化权限和完整的审计轨迹，有助于降低风险，提高生产力，让用户对数据驱动的决策充满信心。通过Rancher协调管理多个Kubernetes集群，使Wdesk能够快速满足客户日益增长的规模需求。 在选择容器管理平台时，Workiva需要一个可靠的解决方案来管理他们大量的生产工作负载，并且要求100%的零停机。同时，Workiva也需要具有复杂的

Service mesh是近几年才出现的一个新兴概念。它可以解决微服务之间通信愈发复杂的问题。那么什么是Service mesh？它有什么具体的功能？它的架构又是如何的呢？它与Kubernetes的关系是怎样的？所有答案戳文了解！ 在数字化转型的旗帜下，IT界的一大变化是大型单体应用程序被分解为微服务架构，即小型、离散的功能单元，并且这些应用程序在容器中运行。包含所有服务代码以及依赖项的软件包被隔离起来，并且能轻松从一个服务器迁移到另一个。 像这样的容器化架构很容易在云中扩展和运行，并且能够快速迭代和推出每个微服务。然而，当应用程序越来越大并且在同一个服务上同时运行多个实例时，微服务之间通信将会变得愈发复杂。Service mesh的出现将解决这一问题，它是一个新兴的架构形式，旨在以减少管理和编程开销的形式来连接这些微服务。 什么是Service mesh？ 关于Service mesh的定义，最为广泛接受的观点是：它是一种控制应用程序不同部分彼此共享数据的方式。这一描述包含了service mesh的方方面面。事实上，它听起来更像是大多数开发人员从客户端-服务器应用程序中熟悉的中间件。 Service mesh也有其独特之处：它能够适应分布式微服务环境的独特性质。在搭建在微服务中的大规模应用程序中，有许多既定的服务实例，它们跨本地和云服务器运行

周末闲逛 Twitter 时，发现一个很有意思的小工具叫 kubeman ，野心倒是不小，励志成为 kubectl 的替代品，用于实时监控和管理 kubernetes 集群，还可以调试与 Istio 相关的问题。 如果只使用 kubectl，当网格中的服务出现问题时，可能需要运行很多命令，而且要交叉引用来自多个命令的输出信息，这就会导致问题分析的过程很复杂。kubeman 将这些交叉引用和相关信息分析的复杂逻辑隐藏起来，只暴露一个 UI 界面，针对每一种资源对象封装了一些常用的操作项，这样可以简化很多操作流程。 安装很简单，到 release 页面下载相应的二进制，然后直接运行就好了。下面通过一个完整的示例来演示它的工作流程： 1、运行 kubeman 二进制文件。 2、点击 Select Cluster 菜单选择集群，还可以在 NAMESPACES 对话框中选择一个或多个 namespace，将后面操作项的会话限制在某些 namespace 中。 3、之前选择的集群 context 现在会显示在顶部。 4、左边一栏是菜单面板，操作项被按照不同的资源类型进行分组，你可以从菜单组中选择一个要执行的操作项。 5、由于操作项的数量很庞大，从中寻找我们想要的操作项可能会很费劲，还好顶部有一个搜索框，你可以通过搜索来找到你想要的操作项，搜索结果会显示在 Matching Recipes

<br />作者 | 阿里云智能事业群高级开发工程师 元毅 导读 ：在实际应用中，通过 APIGateway（即 API 网关），可以为内部服务提供保护、提供统一的鉴权管理、限流、监控等能力，开发人员只需要关注内部服务的业务逻辑即可。作者元毅在本文中将会为大家介绍：如何通过阿里云 API 网关以及内网 SLB，将 Knative 服务对外发布，以打造生产级别的 Knative 服务。 关于阿里云 API 网关 阿里云 API 网关为您提供完整的 API 托管服务，辅助用户将能力、服务、数据以 API 的形式开放给合作伙伴，也可以发布到 API 市场供更多的开发者采购使用。 提供防攻击、防重放、请求加密、身份认证、权限管理、流量控制等多重手段保证 API 安全，降低 API 开放风险 提供 API 定义、测试、发布、下线等全生命周期管理，并生成 SDK、API 说明文档，提升 API 管理、迭代的效率 提供便捷的监控、报警、分析、API 市场等运维、运营工具，降低 API 运营、维护成本 基于阿里云 API 网关发布服务 绑定 Istio 网关到内网 SLB 创建内网 SLB，绑定 Istio 网关应用。可以直接通过下面的 yaml 创建内网 SLB： apiVersion: v1 kind: Service metadata: annotations: service.beta

Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是K8S成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 Istio的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。 阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单Istio问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了Istio，并依照官方文档部署bookinfo应用来上手Istio。部署之后，用户执行kubectl get pods命令，发现所有的pods都只有二分之一个容器是READY的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0 1m productpage-v1-5cb458d74f-28nlz 1/2 Running 0 1m ratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1m reviews-v1-56f6855586-dplsf 1/2 Running 0 1m reviews

进入21世纪以来，我们见证了企业分布式应用架构从SOA(Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业IT系统的复杂度会越来越高。 第二，在计算机交互设计中有一个著名的 复杂性守恒定律 。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。 听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？:-) 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 蜕变之痛 - SOA 2004年，IBM建立SOA全球设计中心，我作为研发TL和架构师参与了一系列全球客户的pilot项目，帮助Pepboys, Office Depot等国际企业利用SOA优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是，随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的IT系统已经经过了数十年的演化

控制 Ingress 流量 到目前为止，Istio提供了一个简单的API来进行流量管理，该API包括了四种资源：RouteRule，DestinationPolicy，EgressRule和Ingress（直接使用了Kubernets的Ingress资源）。借助此API，用户可以轻松管理Istio服务网格中的流量。该API允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等等，所有这些功能都不必更改应用程序本身的代码。 虽然目前API的功能已被证明是Istio非常引人注目的一部分，但用户的反馈也表明，这个API确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用HTTP以外的协议时。 此外，使用Kubernetes Ingress资源来配置外部流量的方式已被证明不能满足需求。 为了解决上述缺陷和其他的一些问题，Istio引入了新的流量管理API v1alpha3，新版本的API将完全取代之前的API。 尽管v1alpha3和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型需要进行手动转换。 Istio接下来的几个版本中会提供一个新旧模型的转换工具。 为了证明该非兼容升级的必要性，v1alpha3 API经历了漫长而艰苦的社区评估过程，以希望新的API能够大幅改进，并经得起时间考验。 在本文中

1 Istio是什么？ Istio 1.0版本于8月1号凌晨准点发布，核心特性已支持上生产环境，各大微信公众号、博客纷纷发文转载。那么Istio到底是什么？能解决问题什么？ 1、 Istio 是Google继Kubernetes之后的又一开源力作，主要参与的公司包括Google，IBM，Lyft等，它提供了完整的非侵入式的微服务治理解决方案，解决微服务的管理、网络连接以及安全管理等应用网络治理问题 2、 它无需修改任何代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及流量监控和治理。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。 2 Istio与Kubernetes Kubernetes 提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流降级、调用链治理等能力. Istio则很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像SpringCloud Netflix等完全重新做一套。Istio是谷歌微服务治理上的非常关键的一环。 3 Istio流量管理能力介绍 Istio，用于连接、保护、控制和观测服务。 今天，我们就来谈谈Istio第一主打功能——连接服务。 那么，便引出3个问题： Istio

Ubuntu 18.04 + Kuberntes 1.11.2 + Istio 1.0组合来了。 完整安装说明，参考： https://linuxconfig.org/how-to-install-kubernetes-on-ubuntu-18-04-bionic-beaver-linux 安装的其它细节问题解决： https://my.oschina.net/u/2306127/blog/1628082 需要容器GPU支持，参考： http://Kubernetes安装GPU支持插件 服务网格Istio安装，参考： Istio 1.0快速安装到Kubernetes集群 安装工具相关脚本资源： https://github.com/openthings/kubernetes-tools 安装Docker #准备软件源 sudo apt install docker.io sudo systemctl enable docker Install Docker -CE add key: https_proxy=192.168.199.249:30999 wget https://download.docker.com/linux/ubuntu/gpg -O docker.key sudo apt-key add docker.key add source sudo echo "deb

导读 ：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的 IT 转型，利用云计算技术推动其成为市场竞争中的敏捷力量。 进入 21 世纪以来，我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业 IT 系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业 IT 系统的复杂度会越来越高。 第二，在计算机交互设计中有一个著名的 复杂性守恒定律 。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。 听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？:-) 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 蜕变之痛 - SOA 2004 年，IBM 建立 SOA 全球设计中心，我作为研发