Q先生

点击左侧的operators,OperatorHub。选择Openshift Virtualization。点击create hyperconverged。页面刷新后左侧出现Virtualization。当右上角出现刷新页面提示后点击刷新页面。

最近由于Vmware的收购,导致了一些困惑.考试是否有其他替代或者更好的虚拟化出路.于是研究了下看红帽的OpenShift Virtualization,它的开源项目叫kubevirt.简单的说这个项目就是以红帽的k8s平台Openshift为基础,在Openshift上通过一系列的插件来实现虚拟化,多网络,虚拟机迁移等功能.同时可以使用k8s的一些资源:svc,网络策略,名称空间等功能提升虚拟化的应用安全和高可用.

手动在/etc/resolv.conf中添加内网DNS后恢复正常,重启后该记录丢失.尝试修改/etc/sysconfig/network-scripts/ifcfg-eth0,追加DNS1和DNS2,重启系统后配置一样丢失.rhel7之前我习惯将脚本放在/etc/rc.local,但考了RH442之后我习惯将开机运行的脚本做成service,这样更易于管理和故障排查.当然放着tuned里面也更不易于被其他人修改和发现.接下来就是批量生效了.由于是生产环境这里就不截图了.给脚本加上可执行权限。

加上nginx.ingress.kubernetes.io/proxy-body-size: 35m即可将限制从20m调整到35m。开发说当附件大于20Mb时会出现[request body too large]的报错.nginx-ingress 他本身有一个限制，正好是20M左右.新环境部署在阿里云,通过WAF—>CLB—>容器服务 ACK。修改后测试了几个30m左右的附件都没什么问题.这套环境附件基本是20m-30m样子.

发现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加上就好了。

k8s集群内通过CoreDns互相解析service名.同时pana.cn域为外部dns解析,需要通过指定dns服务器进行解析再有3个服务器,需要使用A记录进行解析。

NOTES:echo)# 服务解析;;;;;;;;;;;;;;;;;;udp: 4096;;;;;;;;;;;;;;尝试使用test123密码登录数据库or \g.owners.Type 'help;| mysql || sys |mysql>这样就说明数据库连接正常。

Debian 是许多其他发行版的基础。例如 Ubuntu、Knoppix、PureOS 以及 Tails，都基于 Debian。由于Centos Steam的原因及Docker镜像大量使用Ubuntu,Debian等原因,必须学习Debian。

按照本实验在 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,实现对流量的权重分配

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

有小伙伴做实验想要实现以下需求:输入www.pana.com/app1访问app1的svc输入www.pana.com/app2访问app2的svc。

起因是要在一组k8s环境下做个Prometheus的测试,当时虚拟机用完直接暂停了.启动完master和node节点后重启了这些节点.当检查dashboard时候发现Pod处于ImagePullBackOff状态,使用命令查看详细情况发现镜像拉取失败。