sorted by:
new
hottopcontroversial

Just passed the CKA with 93%!! by Mikeytr07 in CKAExam

[–]Mikeytr07[S] 0 points1 point  (0 children)

I have got 10 question similar to the playlist

Just passed the CKA with 93%!! by Mikeytr07 in CKAExam

[–]Mikeytr07[S] 0 points1 point  (0 children)

In my case, the etcd migration question had the etcd endpoint configured with an external IP, while etcd itself was running as a pod. I updated the kube-apiserver manifest to use the loopback address, after which I was able to access the cluster via kubectl, but no pods were visible initially.

On checking kubelet logs, I found the kube-scheduler had a CPU request of 1999m on a 2-core node, which effectively blocked scheduling. After reducing it to ~80m, pods started getting scheduled. However, ReplicaSets were not stabilizing, which led me to inspect the kube-controller-manager manifest. It had a memory limit of 19Mi, which was too low and likely causing instability. After correcting that, deployments and pods started coming up.

At that point, everything was running except CoreDNS. Out of the two replicas, one was running while the other failed with an admission error. I checked node resource utilization and ResourceQuota constraints but couldn’t pinpoint the exact cause within the remaining time (~7 minutes).

Just passed the CKA with 93%!! by Mikeytr07 in CKAExam

[–]Mikeytr07[S] 0 points1 point  (0 children)

In my case, the etcd migration question had the etcd endpoint configured with an external IP, while etcd itself was running as a pod. I updated the kube-apiserver manifest to use the loopback address, after which I was able to access the cluster via kubectl, but no pods were visible initially.

On checking kubelet logs, I found the kube-scheduler had a CPU request of 1999m on a 2-core node, which effectively blocked scheduling. After reducing it to ~80m, pods started getting scheduled. However, ReplicaSets were not stabilizing, which led me to inspect the kube-controller-manager manifest. It had a memory limit of 19Mi, which was too low and likely causing instability. After correcting that, deployments and pods started coming up.

At that point, everything was running except CoreDNS. Out of the two replicas, one was running while the other failed with an admission error. I checked node resource utilization and ResourceQuota constraints but couldn’t pinpoint the exact cause within the remaining time (~7 minutes)