Openshift安装istio
参考istio官网：https://istio.io/docs/
Service Mesh VS kuberneters
优势
kube-proxy是全局代理配置，牵一发而动全身，而Service Mesh能提供更加细粒度的控制。
sidecar proxy抽象了service的概念，支持更多的扩展。
劣势
Service Mesh带来的挑战
配置、同步、最终一致性、资源占用率等。
更高的学习成本和调试成本。
nginx controler VS Istio gateway（七层代理）
优势
支持多种协议：gRPC，http2，tcp，mysql，redis等
支持多种路由控制
支持多种发布方式
支持多种upstream probes
劣势
学习成本。
思考
是否有必要迁移进来需要综合考虑，务必做好充分的测试。
概念
Envoy 被部署为 sidecar，和对应服务在同一个 Kubernetes pod 中。这允许 Istio 将大量关于流量行为的信号作为属性提取出来，而这些属性又可以在 Mixer 中用于执行策略决策，并发送给监控系统，以提供整个网格行为的信息。
Citadel 通过内置身份和凭证管理赋能强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁可以访问您的服务，而不是基于不稳定的三层或四层网络标识。
Galley 代表其他的 Istio 控制平面组件，用来验证用户编写的 Istio API 配置。随着时间的推移，Galley 将接管 Istio 获取配置、 处理和分配组件的顶级责任。它将负责将其他的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来。
Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。有关属性提取和策略评估的更多信息，请参见 Mixer 配置。
Mixer 中包括一个灵活的插件模型，使其能够接入到各种主机环境和基础设施后端，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。
Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。
Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 都可以使用的标准格式。这种松散耦合使得 Istio 能够在多种环境下运行（例如，Kubernetes、Consul、Nomad），同时保持用于流量管理的相同操作界面。
1.在 Helm 和 Tiller 的环境中使用 helm install 命令进行安装
https://istio.io/zh/docs/setup/kubernetes/install/helm/
1.1安装配置说明：
https://istio.io/zh/docs/setup/kubernetes/additional-setup/config-profiles/
1.2 Istio对Pod 和服务的要求
https://istio.io/zh/docs/setup/kubernetes/additional-setup/requirements/
需要给端口正确命名，默认被视为普通 TCP 流量
Deployment 应带有 app 以及 version 标签
2.openshift需要授权
https://istio.io/zh/docs/setup/kubernetes/prepare/platform-setup/openshift/
oc adm policy add-scc-to-user anyuid -z istio-ingress-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z default -n istio-system
oc adm policy add-scc-to-user anyuid -z prometheus -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-egressgateway-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-citadel-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-ingressgateway-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-cleanup-old-ca-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-mixer-post-install-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-mixer-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-pilot-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-sidecar-injector-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-galley-service-account -n istio-system
oc adm policy add-scc-to-user anyuid -z istio-security-post-install-account -n istio-system
运行应用的 Service account 需要在安全上下文中具备一定特权，这也是 Sidecar 注入过程的一部分：
oc adm policy add-scc-to-user privileged -z default -n
bookinfo示例：
https://istio.io/zh/docs/examples/bookinfo/
oc adm policy add-scc-to-user privileged -z bookinfo-details -n istio-system
oc adm policy add-scc-to-user privileged -z bookinfo-productpage -n istio-system
oc adm policy add-scc-to-user privileged -z bookinfo-ratings -n istio-system
oc adm policy add-scc-to-user privileged -z bookinfo-reviews -n istio-system
集群用的是手工 Sidecar 注入，使用如下命令：
oc apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml)
创建route绑定productpage 9080端口，访问即可 http://$GATEWAY_URL/productpage
刷新几次应用的页面，就会看到 productpage 页面中会随机展示 reviews 服务的不同版本的效果（红色、黑色的星形或者没有显示）。reviews 服务出现这种情况是因为我们还没有使用 Istio 来控制版本的路由。
应用缺省目标规则
oc apply -f samples/bookinfo/networking/destination-rule-all.yaml
oc get destinationrules
NAME HOST AGE
details details 6m
istio-policy istio-policy.istio-system.svc.cluster.local 7d
istio-telemetry istio-telemetry.istio-system.svc.cluster.local 7d
productpage productpage 6m
ratings ratings 6m
reviews reviews 6m
配置请求路由（应用 virtual service）
https://istio.io/zh/docs/tasks/traffic-management/request-routing/
要仅路由到一个版本，请应用为微服务设置默认版本的 virtual service。在这种情况下，virtual service 将所有流量路由到每个微服务的 v1 版本。
oc apply -f virtual-service-all-v1.yaml
oc get virtualservices
NAME GATEWAYS HOSTS AGE
details [details] 16s
productpage [productpage] 16s
ratings [ratings] 16s
reviews [reviews] 16s
您已将 Istio 配置为路由到 Bookinfo 微服务的 v1 版本，最重要的是 reviews 服务的 v1 版本。
请求http://$GATEWAY_URL/productpage 无论您刷新多少次，页面的评论部分都不会显示评级星标。
基于用户身份的路由
来自特定用户的所有流量路由到特定服务版本。在这种情况下，来自名为 Jason 的用户的所有流量将被路由到服务 reviews:v2。
Istio 对用户身份没有任何特殊的内置机制。这个例子的基础在于， productpage 服务在所有针对 reviews 服务的调用请求中 都加自定义的 HTTP header，从而达到在流量中对最终用户身份识别的这一效果。
reviews:v2 是包含星级评分功能的版本。
创建规则并确认
oc apply -f virtual-service-reviews-test-v2.yaml
oc get virtualservices reviews -o yaml
以用户 jason 身份登录访问可以看到星星，其它用户流量都被路由到 reviews:v1
清理
samples/bookinfo/platform/kube/cleanup.sh