Hey all, I passed the CKA exam and want to say thanks to the KodeKloud team and . . .

Basky:
Hey all, I passed the CKA exam and want to say thanks to the KodeKloud team and @Mumshad Mannambeth. Below, I have shared my experience and some suggestions.

• Do all the mocks provided as part of the KK course, and once you are comfortable, move to the next step.
• Enroll in the exam one week before the scheduled date to gain access to the killer.sh mock.
• Take the mock, and it may be challenging for the first time. I scored 37 on my first attempt.
• Review all the questions after the timeout and make sure you understand the concepts.
• Try the killer mock again to ensure that you can adapt to the environment, including copy/pasting and browsing (remember that the mock will only be available for 36 hours).
• Try as many mocks as possible from the KK CKA mock exam series to increase your speed of completion.
A couple of edge cases to consider are:
• How to configure pod/namespace selectors for pods/namespaces without labels
• How to quickly test whether the service (cluster/nodeport) is working using a temporary busybox container
• How to quickly check the rbac for service accounts using the ‘can-i’ and ‘as’ options
• How to identify the path of the control plane service when configured as a pod/service.
Even though I used Kubernetes as a backend developer, going through the CKA exam gave me more visibility of the underlying architecture and operational knowledge. I wish everybody all the best.

Trung Tran:
Awesome, thanks for sharing this, will help other members on their cert journey!

R:
congratulations @Basky Request to clarify #1 “How to configure pod/namespace selectors for pods/namespaces without labels”

Logically thinking, if its required then I would add the label to the pod and use it

R:
• How to identify the path of the control plane service when configured as a pod/service.
• ==> this will. be the /etc/kubernetes/manifest/

Basky:
For namespace selector we can use ‘matchNames’

apiVersion: http://networking.k8s.io/v1|networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dev-ingress
spec:
podSelector:
matchLabels:
app: myapp
ingress:

  • from:
    • namespaceSelector:
      matchNames:
      • my-namespace

For podselector we can use matchExpressions with fieldselector:

apiVersion: http://networking.k8s.io/v1|networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-pod
spec:
podSelector:
matchExpressions:
- { fieldSelector: metadata.name=my-pod-without-labels }
policyTypes:

  • Ingress
    ingress:
  • {}

Basky:
• How to identify the path of the control plane service when configured as a pod/service.
For static pods yes /etc/kubernetes/manifest. But for systemd service it is different. Use ‘systemctl cat service name’ to get the details

Mumshad Mannambeth:
@Basky Thank you for sharing your experience.

R:
@Basky I tried both your approaches mentioned above, I am getting errors. Not able to make it work

controlplane ~ ➜  cat test1.txt 
apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>
kind: NetworkPolicy
metadata:
  name: allow-dev-ingress
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - namespaceSelector:
        matchNames:
        - my-namespace
    ports:
    - protocol: TCP
      port: 8080

controlplane ~ ➜  k create -f test1.txt
Error from server (BadRequest): error when creating "test1.txt": NetworkPolicy in version "v1" cannot be handled as a NetworkPolicy: strict decoding error: unknown field "spec.ingress[0].from[0].namespaceSelector.matchNames"

Rob Thorne:
@R The error message is telling you that “matchNames” isn’t a legal subfield of namespaceSelector. You can look up what fields are legal by using the explain subcommand:

k explain netpol.spec.ingress.from.namespaceSelector

which will tell you that that what you can use are matchExpressions and matchLabels . I’d probably use matchLabels with a label pair from the namespace I want to use; do

k get ns my-namespace --show-labels

to get something to use. <http://kubernetes.io/metadata.name=my-namespace|kubernetes.io/metadata.name=my-namespace> would be created automatically by the system, and would be something you could use.

R:
Thank @Rob Thorne I will try it now. I was trying exact steps as mentioned by @Basky

Nithya Subramani:

  policyTypes:
    - Ingress
    - Egress
  ingress:

Nithya Subramani:
You have never mentioned policyType. Kindly define that and try to create it

Nithya Subramani:
Also I think there is no “matchName” option in namespace selector. Only matchLabels is available