Q先生

平时工作或学习中Docker和k8s已经是必备的技能和工具了.但很多时候由于某些原因无法顺畅的从Docker Hub上下载镜像.特别是一些比较急的时候,越是急越是拉不下来.之前也写过一篇"利用阿里云下载国外镜像,国内顺畅下载k8s.gcr.io的镜像",但由于步骤比较多,每次下载不同的镜像都需要通过大量的手工步骤才能完成镜像的拉取.本文介绍的方法彻底解决以上问题,只需要2步就能完成镜像的下载.修改github仓库中的images.txt文件,将镜像以每行一个的方式保存。

环境下默认上传文件大小为5M,开发要求将上传文件限制改成500MB。服务是在阿里云的ACK环境下,用Ingress做路由入口。修改Ingress,在metadata:下加入以下行。

红框中就是密码,所以密码是root123。

重启完毕后确认分区是否挂载,文件是否可以正常访问。问题可能就发生在这次缩盘的时候。配置开机自动挂载后重启服务器。确认下问题可能出现在哪里。

可以看到除了ls以外没有其他命令再访问或者修改这个目录了.且目录的权限不再变化。根据日志的内容,我们看到是一个python脚本进行的修改.很明显有一个service调用这个脚本,那么停止并禁用它。那么我们先找到这个文件,然后再看是什么东西运行的。再次确认下是否还有正在运行的,如果有就kill掉。那么禁用这个crontab就可以了.再确认是哪个crontab调用的.再确认是否有crontab调用它。

以下仅是自己考前练习,和考试无任何关系.

花了2年时间,终于把RHCA搞的差不多了.RH342是第10门。

蓝绿部署、灰度发布、金丝雀发布和滚动更新都是软件部署策略，旨在减少发布新版本时的风险，提高系统的稳定性和用户体验。

在Kubernetes（K8s）中，Pause容器是一种特殊类型的容器，它的主要作用是充当依赖其他容器的容器，为其他容器提供一个可靠的、隔离的运行环境。

Kubernetes中的资源请求和限制是通过与容器运行时的交互来实现的，确保容器在启动时有足够的资源可用，并且在运行时不会超过设定的资源限制。这些机制有助于提高集群的稳定性和可靠性，防止资源耗尽导致的系统崩溃。

在Kubernetes集群中，节点NotReady状态表示该节点当前不可用或不健康，无法接受新的工作负载或调度新的Pod。

选择哪个网络插件取决于具体的应用场景和需求。如果只需要基本的网络连接，Flannel 足够；如果需要更强大的网络策略和更好的性能，Calico 是一个不错的选择；如果对性能要求极高，Cilium 是最佳选择，但需要更高的学习成本。常见的K8s网络插件有Flannel,Calico,Cilium,Weave,Antrea,Kube-OVN等.其中Calico, Flannel, 和 Cilium较为常用.

kube-proxy是Kubernetes集群中非常重要的组件，它确保了Service的网络可用性和负载均衡功能。，它在每个节点上运行，主要负责实现Service的网络代理和负载均衡功能。是Kubernetes集群中一个。

如果你的应用程序是无状态的，并且你希望快速、简单地部署和管理它，那么 Deployment 可能是一个更好的选择。如果你的应用程序是有状态的，并且你需要维护 Pod 的状态、网络标识和持久化存储，那么 StatefulSet 可能更适合你。当然，在实际应用中，你可能会遇到更复杂的情况，需要结合使用 Deployment 和 StatefulSet，甚至其他 Kubernetes 资源，以满足你的需求。

在Kubernetes中，Pod是核心资源对象，其稳定运行至关重要。然而，Pod可能会遇到各种错误状态，影响其正常运行。

用户操作：用户通过kubectl命令行工具或API接口提交一个Pod的定义，通常是通过YAML或JSON格式的配置文件来描述Pod的详细信息，包括容器镜像、环境变量、资源需求、卷挂载等。

Kubernetes（简称K8s）是一个开源的容器编排平台，旨在自动化应用的部署、扩展和管理。它的架构设计旨在提供高可用性、可扩展性和自动化运维能力。

面试题整理----谈谈对k8s的理解21. Service 资源1.1 ServiceClusterIPNodePortLoadBalancerIngressExternalName1.2 Endpoints1.3 Ingress1.4 EndpointSlice1.5 IngressClass2. 配置和存储资源2.1 ConfigMap2.2 Secret2.3 PersistentVolume2.4 PersistentVolumeClaim2.5 StorageClass2.5.1 PV,PVC,S

ReplicaSet：适用于需要简单副本管理的应用。Deployment：适用于需要高级部署策略的应用。DaemonSet：适用于需要在每个节点上运行的服务。：适用于有状态应用，需要稳定的网络标识和持久化存储。通过选择合适的控制器，可以更好地满足不同类型应用的需求，提高 Kubernetes 集群的灵活性和可管理性。

常见的NFS CSI除了本文中的csi-nfs之外还有nfs-subdir-external-provisioner。证明我们的yaml是没有问题的,那么问题可能出在NFS服务端。回到nfs服务器也可以看到/nfs下对应的pvc目录被创建。在node节点上可以获取到nfs并挂载读取到nfs的内容。可我们明明(rw)了为啥没权限写入,可能问题就在这里了.在容器中创建一个文件,并在nfs服务器上可以正常读取到。可以看到目录被正常挂载到了pod的/var/www。至此K8s集群可以正常挂载集群外的NFS了。

SELinux的安全策略通常存储在。

练习环境好久没开了,今天打开看到kube-controller-manager-k8s-master01和kube-scheduler-k8s-master01状态始终是CreateContainerError.如下图。先停止kubelet,删掉所有容器后重启kubelet就好了。如果是docker的话就把crictl改成docker就好了。造成报错的原因主要就是master上的容器有问题。确认所有pod恢复正常。查看日志也是一些报错。

中编辑zabbix_agent2.conf,追加HostMetadataItem=system.uname。修改/etc/zabbix/zabbix_agent2.conf 主要就是这4行。安装后在C:\Program Files\Zabbix Agent 2。再切到主机查看,此时zabbix-server也已经被添加上来了.至此,Zabbix服务器搭建和Win Linux客户端追加完成.稍过片刻后2个非zabbix-server的客户端被自动发现。再添加一个不包含Zabbix的选项。

这次点亮了整个Vmware Vsphere to Redhat Openshift Virtualization的技能树,至少证书层面.最后一块拼版就是DO316.同时RHCA也Level IV了。

最近由于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记录进行解析。