Q先生

发现sleep的pod没有sidecar,那么编辑deployment确认没有加载sidecar原因。考试时间是完全充足的,足够检查和排错的时间.所以一定要仔细检查,因为复制和粘贴出错丢分就很可惜了。考试时候90%的关键字会用红色标出,在做完所有考题后,再次一一确认每题yaml中的各个值.练习时,经常会因为复制粘贴的原因造成某个值复制不完全.这种问题一般比较难发现.整个考试2小时,实际耗时50分钟,由于准备较为充分基本没有遇到什么异常问题.再次执行命令,确认sleep变成2/2。

这题记得workloadSelector即可,可以通过页面或者kubectl explain获取到.再就是缺release: dev部分,可以从。考试也没提供相关资源,不用额外测试。直接在题目中复制,以下内容。只要补上这3行其他不用修改。

这题基本和上一题是一样的,唯一可能有问题的就是AuthorizationPolicy.spce.rules.from.source.namespaces和kubectl explain AuthorizationPolicy.spec.rules.to.operation.paths。这题考试没给相关资源,不用做额外的测试,只要记得如何获取namespaces和paths的方法就可以了.这题同上一题一样,用的是同一个模板,可以直接将上一题复制然后再上一题的基础上修改。可以用命令,一点点获取到。

稍微等1分钟左右,让策略分发完毕,再次运行。执行(题目中第三行给出以下命令)执行yaml生效配置。

这题修改内容正确即可,不需要额外测试。

这题考试时候ns下并没有资源所以也没法测,改起来也方便.只要yaml没错也就对了.

部署2个测试容器,分别是test和test2.test注入标签subset=v1。这里文档中省略了metadata的3行,可以从前面任意一个yaml复制粘贴过来。通过test2测试容器访问,50%概率触发500故障注入。通过test测试容器访问,20%概率触发延迟注入。发起20次请求,一共10次被500。

这里由于没有超时,所以也看不出效果.

至此此题配置测试完毕,这题是整个考试中最复杂的一题,其实修改的内容也不是特别多,且模板内容都在同一个页面的连续位置上.所以熟悉了之后也就这样.再查看sidecar的日志,可以看到是由sidecar发起的。可以看到最后一条就是访问example.org的。在egress ns下创建一个测试的pod。通过该pod访问example.org。再查看istio-egress的日志。域名可以用vi的替换进行批量修改。可以看到并不是直接从它上面出去的。这题一共需要4段配置.查看测试pod的日志。

2.在oscorp-dev中创建一个oscorp.example.com的vs,测试是否能绑定gw oscorp-prod。3.在oscorp-dev中创建一个aaa.example.com的vs,测试是否能绑定gw oscorp-prod。4.在default中创建一个oscorp.example.com的vs,测试是否能绑定gw oscorp-prod。2.在oscorp-dev中创建一个oscorp.example.com的vs,绑定gw成功,返回值200。这个测试比较麻烦,考试时候可以不做.

【代码】Istio ICA考试之路---2-4。

这里看到ns有这个label就可以了,第一次练习的话可以在这个ns中创建一个pod看是不是带sidecar。查看详细的话可以看到sidecar正是istio注入的istio-proxy。如果忘记参数的话可以看下其他ns的label,然后抄上去就可以了.这题还是比较简单的,也是工作中用的比较多的.我们直接看上几题的ns就可以了。把label加上就好了。

找到dr部分,这部分可以在mirroring里找也可以和题2-1一样在Traffic Management的dr里复制,内容都一样。此题之后都是在cluster-2上操作,所以就不需要再切换了.之后的几题2.1节就忽略掉了。可以看到,80%的流量被镜像到了dev上,实际考试这步可以忽略。看到ex-ip是192.168.126.220。获取gw,把gateways加入到vs配置中。获取istio-ingress的ex-ip。就获得了这样一个模板文件。查看2个pod的日志。

由于不同版本Istio的yaml有细微区别,练习时要切换到对应版本的帮助文档上.考试时不用切换,有且只有1个版本的.这题如果忘记切,往下做会报没有这个ns,再回头切上下文就可以了。我练习环境部署的是1.18.2那么就切到这个版本。可以看到v1和v2的比例就是我们设定的4比6。接下来根据题意先获取dr和vs的模板。老规矩,#结尾的行是需要按题意修改的。

选择题选完之后如果切到其他题再回来位置会发生变化。

确保* 在cluster-1上,否则直接把cluster-2搞坏了后面的题就没法做了.这2步考试没必要执行。

从21年初开始接触学习istio24年3月开始准备ICA考试24年4月ICA考试经历大概由选择题变为实操题24年5月18日完成ICA考试,19日收到通过邮件Istio整个学习过程大概200个小时左右.准备考试大概40个小时左右.啥也不说上图。

按照本实验在 cluster1（主集群）上安装 Istio 控制平面，并将 cluster2（远程集群）配置为使用 cluster1 中的控制平面。群集 cluster1 在 network1 网络上，而 cluster2 在 network2 网络上。这意味着 Pod 之间没有跨越群集边界的直接连接。在此配置中，cluster1 中的 Istiod 将监视两个集群中的 APIServer 的端点。通过这种方式，控制平面将能够为两个集群中的工作负载提供服务发现。

按照本实验，在 cluster1 和 cluster2 两个集群上，安装 Istio 控制平面， 且将两者均设置为主集群（primary cluster）。集群 cluster1 在 network1 网络上，而集群 cluster2 在 network2 网络上。这意味着这些跨集群边界的 Pod 之间，网络不能直接连通。在此配置中，cluster1 和 cluster2 均监测两个集群 API Server 的服务端点。

至此备考ICA----Istio实验18—单集群中部署多个Istio控制面实验完成。usergroup1 安装istio。usergroup2 安装istio。确认pod被正确创建。

可以看到我们仅限制了9000端口,当访问9000端口时访问被拒绝,当访问9001端口,请求被响应。放行kim命名空间下,tcp-echo的9000和90001访问。至此备考ICA----Istio实验17—TCP流量授权实验完成。可以看到之前9000可以被正常访问,9001访问被拒绝。检测环境的9000和9001端口。

访问测试。

在某些生成环境下,我们希望微服务和微服务之间使用加密通讯方式来确保不被中间人代理.默认情况下Istio 使用 PERMISSIVE模式配置目标工作负载,PERMISSIVE模式时,服务可以使用明文通讯.为了只允许双向 TLS 流量，需要将配置更改为 STRICT 模式。

为 edition.cnn.com 创建一个出口，端口 80，并为定向到出口网关的流量创建一个目标规则metadata:spec:selector:servers:- port:number: 80name: httphosts:---metadata:spec:subsets:部署。

备考ICA----Istio实验13—使用Istio Ingress TLS暴露应用1. 环境部署清理之前实验遗留,并重新部署httpbin服务进行测试# 清理之前的环境kubectl delete vs httpbinkubectl delete gw mygateway# 部署httpbinkubectl apply -f istio/samples/httpbin/httpbin.yaml 确认应用被正确创建kubectl get deployments,svc httpbin

本实验部分配置延续上个Istio实验11。

在vs中定义了监听mygateway的hosts是pana.example.com,匹配上uri:/hello后转发给svc helloworld的后端进行响应.这里新的hello服务和上个实验合用mygateway这个gateway对外提供访问,但各自使用各自的TLS证书.因为后续也是使用istio/ingressgateway所以必须放着istio-system命名空间下。可以看到2个服务使用了同一个gw,但各自又有自己的Vs。上一个实验部署的httpbin.example.com。

部署httpbin。

创建httpbin环境。

将环境恢复到刷新随机到3个不同版本的reviews上v1v2v3流量随机分配到3个版本。

Istio 的故障注入用于模拟应用程序中的故障现象，以测试应用程序的故障恢复能力。故障注入有两种:1.delay延迟注入2.abort中止注入。

流量镜像功能可以将生产的流量镜像拷贝到测试集群或者新的测试版本中，在不影响实际生产环境的情况下，测试具有实际生产流量的服务，帮助减低版本变更的风险。也可以用在不同集群间的同步。

该服务通过标签app: tcp-echo选择服务,服务tcp-echo存在2个版本,分别是v1和v2部署服务。

上一个实验已经通过DestinationRule实现了部分金丝雀部署的功能,这个实验会更完整的模拟展示一个环境由v1慢慢过渡到v2版本的金丝雀发布.

金丝雀发布,通过Destination定义多个subnet,实现对流量的权重分配

创建hello服务,通过Istio ingressgateway进行流量转发

打算2024年4月份考Istio的ICA认证,系统的再把Istio相关功能的实验再摸排一遍本套实验环境如下。

【云原生 | Kubernetes 系列】--Istio Bookinfo 示例

【云原生 | Kubernetes 系列】--Istio基础和部署