阿里云istio（阿里云盘网页版）

本文目录一览：

• 1、Istio是什么？
• 2、2020-06-09【阿里云ECS搭建minikube和Istio1.6】(2)
• 3、阿里云istio使用初体验
• 4、Istio 1.6 版编译简明教程
• 5、Istio 常见问题 - Istio 支持 HTTP/1.0

Istio是什么？

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络，而不需要对服务的代码进行任何修改。你只需要在部署环境中，例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持，用来截获微服务之间的网络流量。

特性：

使用istio的进行微服务管理有如下特性：

流量管理：控制服务间的流量和API调用流，使调用更可靠，增强不同环境下的网络鲁棒性。可观测性：了解服务之间的依赖关系和它们之间的性质和流量，提供快速识别定位问题的能力。

策略实施：通过配置mesh而不是以改变代码的方式来控制服务之间的访问策略。

服务识别和安全：提供在mesh里的服务可识别性和安全性保护。

未来将支持多种平台，不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。

正是 Istio 的出现使 “Service Mesh”（ 服务网格 ） 这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解为多个微服务。虽然这种方式简化了单个服务的开发，但对于成百上千的微服务的通信、监控以及安全性的管理并不是一件简单的事。

直至目前，对于这些问题的解决方案也只是通过自定义脚本、类库等方式将服务串联在一起，并且投入专门的人力以处理分布式系统的管理任务。但这种方式降低了各个团队的效率，并且提高了维护的成本。这正是 Service Mesh 大显身手的时机

Istio以及Service Mesh的未来

2020-06-09【阿里云ECS搭建minikube和Istio1.6】(2)

愿每天太阳升起的时候，你都对这个世界存有爱意。

最近在研究Istio1.6新特性，于是想自己搭一个试试看。计划是这样的：

1）买一台阿里云ECS，用CentOS系统；

2）装一个minikube，跑一个Guestbook应用验证成功；

3）再装一个Istio1.6，跑一个Bookinfo应用验证成功。

计划是一天弄好，但是看起来很简单的事情，还是遇到了很多问题，花了两天的时间才终于弄好，分享给各位。本文是第二篇，介绍Kubernetes示例程序验证和反向代理Ngnix的配置。

Guestbook是一个PHP Web应用，包括frontend、redis-master和redis-slave三个微服务。

其中，redis-master服务处理写请求，redis-slave服务处理读请求。

具体配置参考 Kubernetes官方文档 。

pod：按照replica，部署了1个redis-master、2个redis-slave、3个frontend，可以看到他们都在 Running状态。

service：

可以看到frontend是通过NodePort起来的，可以通过命令获得访问地址：

或者直接使用;ECS 私有ip: 80映射端口(30004）访问即可。

由于用ECS的公网IP一直访问不到服务，于是想到用nginx做一个转发，不知道官方正解是什么，感觉每个服务都要配转发规则实在是有点儿原始。

首先想到用docker起一个nginx container，在里面配置转发规则。

还是访问不到，我猜是请求直接转发到container内部，但是想要访问的服务并不是起在容器内部，所以访问不到（不知道我的猜测对不对）。

于是放弃docker的方式，选择直接在ECS里安装nginx。

下一篇将介绍Istio1.6安装和示例程序Bookinfo的配置。

使用官方命令启动k8s应用一直卡在init阶段，查看event发现拉镜像失败。

原因：

k8s的镜像默认都是从谷歌拉，由于科学上网，只能借助开源项目 拉镜像，再手动tag。

解决办法：

参照

1）添加pull-google-container工具脚本 pull-google.sh:

2）放到/usr/local/bin下面：

3）使用pull-google-container命令，他直接做好image名称替换-拉image-打标签，非常省心。

如果想将LoadBalancer的类型切换到nodeport，可通过这个命令设置：

kubectl patch service istio-ingressgateway -n istio-system -p '{"spec":{"type":"NodePort"}}'

之后通过私有IP+80端口的形式使用HTTP访问。

HTTP/1.1 426 Upgrade Required

Upgrade: HTTP/2.0

Connection: Upgrade

原因：

nginx反向代理默认走http 1.0版本，但是被反向代理的container走的是1.1版本

解决办法：

转发处配置支持http1.1

原因：

只对/productpage路径下的资源进行了转发，css、js等资源不在该路径下就找不到了。

解决办法：

配置 proxy_set_header 增加对css和js等资源的转发。

istiod 是一个单体应用，它用较低的复杂性提供了和之前版本一致的功能。组成旧版控制平面的服务都还以子模块的方式存在于项目之中，但提供了更好的运维体验。操作者只需关注单一二进制文件的运行和升级了。简言之，把之前复杂的控制面组件（Pilot、Gallery、Injector、Mixer和Citadel）作为内部子模块放到istiod里。

有两篇文章对istiod的内容作了介绍，讲的挺好，推荐看一下：

（译）Istiod——回到单体的理由

Service Mesh 化繁为简: 基于 Istiod 回归单体设计

阿里云istio使用初体验

由于阿里云在整合istio时, 进行了内部定制,导致好多外部资料上编写的通过istioctl指令操作的步骤,无法在ask/asm上实施.

参考:

部署内容为python接口服务, 有两个版本, 对应两个deployment.

这里直接用kubectl 部署两个版本应用, 同时部署一份service

由于上一篇文章中, 已经对当前namespace做了自动注入istio-agent的label, 所以, 在查看pod 信息的时候, 会发现pod里的containers 为2

编写纯k8s风格的部署文件:

第2步相当于在集群内部署了一份客户端, 现在可以通过kubectl 登录到客户端上, 进行服务验证

登录后, 执行pod里自带的http命令, 进行服务验证

多次执行: http --body , 查看结果:

利用pod 的label, 把pod分成两类, 流量定义如下

其中, host字段的值, 可以理解为Service 的名称.

注意: 这里的 apiVersion 是istio独有的, 所以在发布时候, 要使用asm的config, 进行发布.

定义一个istio的vs(VirtualService), 指定默认的请求流量, 全部打到 v2 的 pod上,

这里的 v2 由上面的 dr 来定义

此时, 再来请求:

此时, 发现所有请求, 全部打到了 v2 节点上.

如上apiVersion所示, 这里使用的是istio的crd, 所以要使用istio的config进行部署.

这里为什么要设置端口 81 呢, 主要是集群里已经有了一个80端口占用,这里直接使用istio ingress 的4层协议, 增加一个81端口转发:

同时, 需要修改上面的VirtualService 配置:

可以使用在线修改方式: kubectl edit vs flaskapp-default-v2 -n demo

主要修改点两个:

然后, 就可以在集群外部, 测试这个接口请求:

到此, 一个完整的istio发布过程结束

Istio 1.6 版编译简明教程

github上Istio自带的说明没法看，又要考虑大墙 ，（官方文档还是OK的，但是墙后还是要做下面的修改） 传送门

NOTE： make clean 虽然是一般编译前的好习惯，在qiang的力量前还是少执行，否则遇到网络不好的时期可能一clean要等好几天才回复元气

核心Makefile包括：

时间略长，偶尔还会出错，耐心~

Makefile

Makefile.core.mk

make init

make docker （过程中遇到出错 需要修改的地方，参看FAQ）

借用阿里云+github编译，可参看 这里

用于登录的用户名为阿里云账号全名，密码为开通服务时设置的密码。

tag的具体名称，和istio具体版本的脚本有关，下面这个带日期的就经常变更，一两周就递进一次吧（所以自己完成这个镜像拉取，还是很有必要的。当然，也可以尝试用旧版本镜像来编译）

tag后，镜像的摘要信息有问题，导致必须做以下处理：

（同上）tag后，镜像的摘要信息有问题，导致必须做以下处理：

但centos默认自带的ruby版本过低

编译生成在如：

Istio 常见问题 - Istio 支持 HTTP/1.0

Istio 默认只支持 HTTP/1.1 以上协议版本，并不支持 HTTP/1.0 。

Istio 中负责流量转发的是 Envoy 。

Envoy 中可以设置支持 HTTP/1.0 。

Istio 负责分配“规则”的是 Pilot 。

Pilot 的环境变量 PILOT_HTTP10 默认为 0 ，即不支持 HTTP/1.0 。

修改 Pilot 的环境变量 PILOT_HTTP10 为 1 。

阿里云安装 Istio 的方式与其他平台不同，因此配置方法需要使用阿里云控制台。

其他平台一般使用 Istioctl 或者 Helm 安装，只要在 Pilot 配置项中加入 PILOT_HTTP10 为 1 即可，下面以 Istioctl 安装为例。