LEARN. PRACTICE. GROW.1. Separate startup phase from service
An application can be running without being ready for traffic. With startupProbe configured, liveness and readiness wait for startup success under their configured delays. Afterwards, readiness controls normal traffic eligibility, and readiness failure alone does not instruct container restart. In an exercise with restartCount zero, readiness 503 and liveness 200, do not invent a single cause. The process answers one check, but its readiness contract needs investigation. A dependency may be unavailable, configuration may be invalid or another application condition may apply; collect evidence before changing probes.
2. Read the right execution
In a Pod containing api and exporter, api logs do not necessarily explain an exporter restart. Identify namespace, Pod, container and current or previous execution. The command using -c exporter --previous requests the previous instance’s logs when available. Do not assume --previous is a full archive of every restart. Retain observation time, events and relevant configuration without recording secrets. For L3 support, this framing reduces context-free escalations: the useful question is which hypothesis the logs can test, not merely whether some output was obtained.
3. Follow selection, port and readiness
A Service can select the right Pods and still lack a functional path. First compare labels and selector. Then compare targetPort: web with Pod-declared port names. If only http: 8080 exists, the web reference is inconsistent. Finally inspect readiness and the listening process. In the compound case, correcting the port name does not explain readiness 503. Address both findings and exercise client function again. The exercise assumes a normal Service without publication of unready addresses; this condition avoids generalizing behavior to intentionally different configurations.
4. Read AND and OR in YAML structure
The intent “payments clients” needs two conditions: a namespace labeled team=payments and a Pod labeled role=client. In one from element, namespaceSelector and podSelector select the intersection. In separate elements they become alternatives: all Pods in selected namespaces, or role=client Pods in the policy namespace. Mentally test four sources: a payments client, payments debug Pod, local client and outside debug Pod. This is not cosmetic indentation; it changes who receives access. Use the fragment below as a reading exercise and justify each result before checking the explanation.
5. Compose policies and test exclusions
Applicable NetworkPolicies combine permissions per direction. A default-deny policy starts isolation, but another policy can allow a flow; adding another default deny does not revoke that allow. Review every relevant policy. For a connection across isolated Pods, source egress and destination ingress must permit the path. This exercise assumes an enforcing CNI, new flows and no hostNetwork or vendor priority extensions. Record these assumptions. A positive check shows permitted access; negative checks using similar sources help reveal an overly broad selector.
6. Close diagnosis layer by layer
Deliver a small evidence matrix: Pod selection, resolved port, Ready state, network permissions and client function. Distinguish what was read in manifests, calculated in a model and observed in a cluster. The local workshop sends no packets and does not validate a CNI. Practical lab work should confirm a permitted source, an excluded source and post-change behavior using authorized namespace and context. The technical manager can then connect the change to acceptance and rollback criteria. Closing merely because one endpoint responded may leave a second defect or unintended exposure unresolved.
# Fragment: NetworkPolicy ingress rule, TCP 8443
from:
- namespaceSelector:
matchLabels:
team: payments
podSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 8443
# Read-only inspection plan for an authorized lab
kubectl logs reconcile-7 -n funds -c exporter --previous
kubectl get service ledger -n ledger -o yaml
kubectl get networkpolicy -n ledger -o yamlrole=debug in team=payments passes a separate namespaceSelector; it fails the intersection with role=client in the same element.
Common pitfalls
Liveness as readiness; Service port as targetPort; two peers as intersection; deny as priority; positive checks as isolation.
Related topics: Deployments and recovery · Services and network policies
Analyze each layer and validate intended access and exclusions.
Reference: Network Policies · CKAD Kubernetes v1.37