Kubernetes runs containerized workloads across a cluster and provides declarative building blocks for deploying cloud-native applications. Its APIs, kubectl CLI, and dashboard support direct operation, but the building blocks are deliberately low level: Kubernetes is also a foundation for more specialized developer platforms. section 1.2
Choose a cluster environment according to what you need to test:
- Local Kubernetes is quick for development and experiments, but a laptop lacks the network behavior, load balancing, and capacity of a real cluster. section 2.1.1
- On-premises clusters behave more like production but require dedicated hardware and an operations team. section 2.1.1
- Managed cloud services offer self-service cluster creation; configuration choices can affect cost. section 2.1.1 section 1.1.4
Run and inspect a distributed application
Create a local cluster with KinD, deploy the Conference application’s services with Helm, then inspect their resources with kubectl. Run `kubectl get pods -owide` to check READY, STATUS, RESTARTS, and NODE. The application also runs Redis, PostgreSQL, and Kafka in the cluster. A restart may reflect a service attempting to connect before a dependency is ready; check whether it subsequently recovers. section 2.0 section 2.2.1
Cluster boundaries also shape multi-tenancy. Sharing a cluster through namespaces can constrain tenant access to cluster-wide resources. Separate clusters provide stronger isolation and administrative freedom, but increase cost and the work of managing a fleet. section 6.2.3
kubectl get pods -owide
Open the pod-listing command used to inspect workload placement and health. section 2.2.1
