小楼一夜听春雨，深巷明朝卖杏花

本质其实就是设置谁可以访问，谁不可以访问。默认命名空间是没有AuthorizationPolicy---允许所有的客户端访问。如果对Pod1生成两个策略，一个是allow，一个是deny，两个冲突的时候那么allow就不再生效了，deny是生效的。这里是没有指定应用到谁上面去，有没有指定使用哪些客户端，这样就是拒绝了所有的了。这个和cka考试里面的网络策略是类似的。它是可以实现更加细颗粒度限制的。上面{}代表着所有的客户端。这个代表是允许命名空间ns1客户端可以访问。但是并不想让所有的客户端都可以访问。

mTLS (mutual TLS，双向TLS)： 让客户端和服务器端通信的时候都必须进行TLS认证默认情况下，在网格内部默认启用了mTLS了。在网格里面所有的pod， 不管是istio使用到的pod，还是普通创建的pod1 pod2，都会通过mtls来进行通信，也就是互相认证。上面其实就演示了网格之外的主机要和pod通信的时候必须得要建立这样一个mtls的通信。对于网格之外的主机，网格外面的主机和pod通信的时候并没有要求使用tls认证。STRICT：工作负载仅接受双向TLS通信。

Istio网关Gateway是一个负责处理南北向流量的组件，它通常会暴露服务网格内部的服务，以便外部的请求能够访问到服务网格中的服务。Istio网关Gateway支持多种协议，包括HTTP、HTTPS和GRPC等。在Istio网关Gateway中，每个服务器都包含一个或多个端口，每个端口都定义了一种协议和相应的配置。Istio网关Gateway还可以定义多个TLS证书，以便对传输的数据进行加密和解密。在配置Istio网关Gateway时，我们需要指定其所使用的负载均衡算法和服务发现机制。

Istio流量治理有故障注入的功能，在接收到用户请求程序的流量时，注入故障现象，例如注入HTTP请求错误，当有流量进入Sidecar时，直接返回一个500的错误请求代码。通过故障注入可以用来测试整个应用程序的故障恢复能力，注入各种故障现象，针对不同的故障现象做出应对措施。使用故障注入时，不可用启用超时和重试的配置，故障注入时在VirtualService资源中进行配置的。

1 tls认证2 设置ACL 允许哪些客户端可以访问 哪些客户端不能访问3 istio里面的认证加密是可以分为三种类型对称加密A要发送数据传送给B，那么A要使用一个密钥，里面写的是密码，要使用密钥对这个数据进行加密。密码给到B那么B是打不开的，因为这个数据是被加密的，这个密码即使被别人截获了也没用的，对于B来说也是打不开的。A要想办法去告诉B说加密密码是haha001。现在A不知道如何将密码告诉给B，所以这是一个问题。

ingress control承载了控制面和数据面的一个职责，在control里面有一个process，这个进程就承担了反向代理的能力，当有任何请求发过来的时候，会被nginx接收到这个请求并且被转发，基于的规则由ingress control动态配置的，所以control就是控制平面，nginx本身就是其数据面。

服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。每一个方框就是一个pod，绿色的部分就是应用代码，蓝色部分就是sidecar。这样应用之间的服务调用就变成了sidecar和sidecar之间调用的一个网。

有一天对于d服务来说，负载压力比较大，可能还有其他应用也会调用到d服务。为了防止某一个服务问题带来的使得整个架构都出现问题，那么可以将某个应用切断，那么这样就将d服务隔离开来了。2、http数据包头有keep-live字段，本次连接不关闭，可以下一次继续发送请求，减少TCP连接。客户端向服务端发请求，需要建立TCP连接，那么建立TCP连接的数量就是连接数。建立连接之后是可以在这个连接上发送请求的，在这个连接上可以发送多个请求的。请求数：（在同一个连接里面发送不同的请求）熔断就是我们生活当中所谓的跳闸，

其实也就是在客户端去访问的时候，如果有一个cookie的值，cookie的值当中含有user，user的值是什么我们不需要管，那么具有相同cookie的值就访问到同一个pod。会话保持就是同一个客户端，连接过来的时候，让其能够访问同一个pod。就是同一个客户端连接过来的时候都是往同一个pod去转发。流量管理-LB调度算法。同时还可以基于ip地址。

定义dr的时候，要指定此dr用于在哪个service上的。这里host就需要修改为svc3。也就是经过svc3的流量将会受到dr的控制。这里定义了两个子集v1 v2，子集的名称是可以自己随意定义的，v1所对应的pod具有标签v1，v2对应的pod具有标签v2。如果按照上面图片上面所定义的就是 v1 run: pod1 v2 run: pod2。在写vs的时候要指定subset，往svc3去转发的，然后往哪个子集去走呢？这里就需要指定v1 v2。

上面就是访问svc2的时候都需要延期2s钟，这样就模拟了pod1去访问pod2的时候需要等待2s。有些时候微服务是多个服务组成的，a服务会去调用b服务，可能因为网络问题或者连接问题，没有连接成功，那么会尝试不断的连接，这样可能消耗很长时间，对用户的体验感会很差。所以a服务去连接b服务的时候，一次没有连接成功的时候，就可以设置一个连接超时时间，比如正常情况下1s就可以连接成功，10s还没有连接成功，那么就是不正常的。所以可以设置过期时间，凡是超过3s钟的，我就认为是不正常的，那么就要去断开这个连接。

warehouse和accounting之间可能会有固定的调用关系，现在的系统架构是要面向失败去做设计的，去设计系统的时候要去假定任何的组件都是不可信的，accounting可能出现故障有两种可能，一种是可以返回错误码，一种是可能不响应了，对于不响应的话，那么很多应用在业务代码里面就写好了返回50x回来。这些更多的是平台侧的能力。sales既然支撑了前端的业务，那么它的可用性的要求会高，它所支持的并发请求也就会越多，这里就可以去部署更多的实例，提供更多的负载并发的支撑，然后提供更高的可用性。

Istio 故障注入与其他在网络层引入错误（例如延迟数据包或者直接杀死 Pod）的机制不同，Istio 允许在应用程序层注入故障。这使得可以注入更多相关的故障，比如 HTTP 错误代码等。Istio 可以注入两种类型的故障，而这两种故障都是使用虚拟服务来配置的：延迟：模拟增加网络延迟或上游服务过载。中止：模拟服务故障而导致调用服务不可用。中止通常以 HTTP 错误代码或 TCP 连接失败表示。

不同的客户端访问同一个地址的时候，转发到不同的服务上面。其实也就是基于不同的客户端将用户的请求转发到不同的pod。aa.rhce.cc/demo1它会帮你去转发到aa.rhce.cc/demo2上面，这个是地址的重写。下面就是请求报文的header里面是chrome那么转发到svc1，其他的情况转发到svc2。这个demo1路径和demo2路径是真实存在的，每个目录下面都有不同的静态文件。这里如果不需要外界访问，那么就不需要创建gw了。得到的结果是demo2。满足特定条件的时候，转发到。

Istio 解决的问题istio所要解决的问题就是流量的管控，之前在pod里面增加了sidecar haproxy就是用来做流量管控的。如果配置了istio就不需要手动的为每个pod去添加sidecar了，而是自动的给我们添加。istio主要解决的问题：流量的管控安全性可观测性（可观测性就是通过可视化界面去看流量的走向）

在Kubernetes集群中，Ingress是授权入站连接到达集群服务的规则集合，可以为您提供七层负载均衡能力，可以通过Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。作为集群流量接入层，Ingress的高可靠性显得尤为重要，本文介绍如何部署一套高性能、高可靠的Ingress接入层。

4.注意证书自己加密的内容是有换行的，k8s内原来的信息没有换行 可以自己手动操作一下。修改为新的证书内容 证书需要通过base64加密。查看现在的证书并编辑内容。3.证书的加密和解密。

nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。稳定和灰度两个版本，灰度版本可以限制只针对部分人员可用，待灰度版本测试完成后，可以将灰度版本升级为稳定版本，旧的稳定版本就可以下线了，我们也称之为金丝雀发布。，对外提供服务的称为绿系统，待上线的服务称为蓝系统，当蓝系统里面的应用测试完成后，，蓝系统将称为绿系统，

可以看到elb绑定的是pod所在节点的ip。

对于我们的gateway来说，它所接受的主机不一定是aa.rhce.cc，可能是bb.rhce.cc还可能是cc.rhce.cc，它能够定义的这些主机很多，我们这里只定义了一个a.rhce.cc。vs一端连着gw，使用gw定义的规则，也就是使用哪个gateway，之后是要将收到的请求转发到哪里去。如果你去访问控制器地址+8888端口是不行的，因为没有监听在这个端口，开放的端口有80 443等端口。这就是入口控制器， 现在得写规则，告诉控制器，凡是访问某个域名的时候，什么端口，什么协议。......

首先v1设置3个副本，v2设置一个副本，这样75%的流量都转发到v1上了，25%的流量转发到v2上。金丝雀发布是这样工作的，我们已经有了一个旧版本的应用这里称之为v1，然后要发布一个新版本的应用这里称之为v2。istio也为我们提供了更强大的安全管理，包括通过AuthorizationPolicy做更细致的授权管理、pod之间的mTLS认证等，极大提高了pod的安全性。如果这10%的用户反馈v2还不错，那么我们我们可以扩大访问v2的流量，缩小访问v1的流量。以此类推，直到把所有的流量逐步转移到v2上面。..

因为没有为其指定应用的域名，所以会转到后端的httpbin和nginx这两个应用，这是不行的。在配置gateway和虚拟服务的时候，里面hosts没有明确的定义是哪一个服务的，都是用*来表示。那么这样就创建了3个80端口，同时是http这样一个gateway。所以要将istio网格这边的服务，暴露到集群外部来，前面加上负载均衡器，然后根据域名去分流。在实际部署中，K8s集群一般部署在内网，为了将暴露到互联网，会在前面加一层负载均衡器（公有云LB产品、Nginx、LVS等），用于流量入口，将用户访问的域名传递

destionationrule主要将3个版本的reviews给匹配上，创建对应的子集subset，并且为其取名，名字可以任意的去取名v1v2v3abc，只要虚拟服务的subset和destionationrule的subset对应上就行了，同时host也对应上。这里有有层级关系，match下面包含了route，请求头里面包含了jason用户就转发到v2版本，下面route对应的是match，除了jason用户之外，其他的引流到v3版本。根据http携带的信息去完成流量的分配。......

istio最重要的是数据平面有个组件叫sidecar，它里面是采用的envoy的代理转发器，拦截所有业务程序的流量，只要你的业务程序接入了istio，到你业务的流量会被proxy接管，最重要的就是管理流量。核心资源： 上面4个是lstio在流量管理实现的具体资源。也即是我们要实现流量管理策略，都是基于这些资源去配置的。 VirtualService（虚拟服务）： 这里创建了gateway，监听的地址是80，只创建监听的路口是不行的，不具备一个转发的功能，下面是其具体的路由规则，service名称和端口。虚拟

查看配置文件的名称，生产环境建议使用default，基本上核心功能都有，minimal是以最小版本去部署的，demo功能多一点，比default多一点。我们这里使用default进行部署安装。下面是查看有哪些配置文件的名称。在install不指定profile那么默认就是使用default。安装的时候后面可以添加--set-profile=default -y部署完查看结果，部署了两个pod，一个istiod，也就是它的控制平面，ingressgateway是用来接受网格流量的，就类似于nginx-i

Service Mesh 的中文译为 “服务网格” ，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。 Sidecar指的是和应用服务部署在一起的一个代理程序，要是访问你的应用要走proxy才能访问到，只能走sidecar去通信，不能走应用和应用之间去通信，因为应用所有的

灰度/滚动发布灰度发布是金丝雀发布的延伸，是将发布分成不同的阶段/批次，每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再增加用户数量进入下一个阶段，直至扩展到全部用户。灰度发布可以减小发布风险，是一种零宕机时间的发布策略。它通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本。整个发布过程会持续比较长的时间, 在这段时间内，新旧代码共存，所以在开发过程中，需要考虑版本之间的兼容性，新旧代码共存不能影响功能可用性和用户体验。当新版本代码出现问题时，灰度发布能够比.

蓝绿发布其实就是一个蓝环境和一个绿环境同时运行，但是同时只有一个对外提供服务，其实也就是启动了两个deployment，service也是两个，最后ingress选择service的时候只需要选择其中一个就行了。如果蓝环境有问题了，那么就可以快速的回退到绿环境。这种情况下就是占用的环境资源较大，完全两套资源。蓝绿发布蓝绿部署是指有两个完全相同的、互相独立的生产环境，一个叫做“蓝环境”，一个叫做“绿环境”。其中，绿环境是用户正在使用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环

对于许多企业来说，将生产环境转移到Kubernetes集群上，会让应用程序的流量管理变得复杂且具有挑战性。而Ingress Controller允许通过Yaml编排脚本提供高可用的七层负载均衡、Waf防火墙或者API Gateway，它是Kubernetes集群对外服务的核心组件。Ingress-nginx是Kubernetes Ingress Controller开源版本中的一种，它使用了NGINX作为反向代理和负载均衡器，生态完善、功能丰富，性能与稳定性也是极优秀的。...

在这里可以看到我已经部署了ingress controll，在使用ingress controll之前要把控制器部署在集群当中，部署好之后创建ingress规则。[root@k8s-master ~]# kubectl get pod,svc -n ingress-nginx -o wideNAME READY STATUS RESTARTS AGE IP NODE .

Ingress是什么NodePort存在的不足：• 一个端口只能一个服务使用，端口需提前规划• 只支持4层负载均衡（iptables ipvs）当应用越来越多的时候，管理端口就会变得麻烦起来了。那么可不可以在集群当中暴露一个端口完成所有项目的统一接入。Nodeport只支持四层的数据包转发，所以不支持基于域名的做分流，基于uri做匹配。有没有只在集群当中暴露一个端口同时是一个全局的负载均衡器可以提供所有项目的统一接入呢？Ingress：Ingress公开了从集群外部到集群内服..