Kubernetes - Objects
When you create a
Service, it creates a corresponding DNS entry.
CustomResourceDefinition (CRD): to extend the Kubernetes API.
- A Kubernetes object is a persistent entities in the Kubernetes system.
- A Kubernetes resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the built-in pods resource contains a collection of Pod objects.
Use controllers to manage pods, do not manage pods directly
Deployment Controller -> ReplicaSet -> Pods
In the simplest cases, each pod just have 1 container, but with sidecar, each pod has 2 containers.
A service provides an unchanging IP, used between frontend deployment and backend deployment.
A service is responsible for enabling network access to a set of pods.
Each service gets a ClusterIP allocated, one ip to get traffic to all the endpoints.
ClusterIP: cluster scoped IP, used internally, the service is not exposed to resources outside the cluster.
NodePort: maps a node port to a service; can be accessed from outside the cluster by requesting
LoadBalancer: Exposes the Service externally using a cloud provider's load balancer.
Services will create
Endpoints, one for each healthy pod. (I.e. each
Endpoint is a
ip:port pointing to the
Pod that is part of this
A deployment is responsible for keeping a set of pods running.
cronjob controller will create jobs
- A deployment without a service: the deployment could be scaled up and down and pods could be replicated. Each pod could be accessed individually via direct network requests, rather than abstracting them behind a service.
- A service without a deployment: create each pod individually then the service routes network requests to the pods.
Deploymentfor stateless services, e.g. web servers.
- Pod replicas in deployments share the same persistent volume.
StatefulSetis for stateful services, e.g. db.
Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
If a volume is configured, each pod will be provision its own persistent volume
Better use headless services (service without an IP address), clients can connect directly to what lies behind it. Headless services has
kind: Service spec: clusterIP: None
DaemonSet: one copy per worker node.
- Service has a stable IP address that lasts for the life of the service; each pod has its own address but pods may come and go and their IP addresses change.
- Service provides load balancing across pods.
applications, app.k8s.io/v1beta1, https://github.com/kubernetes-sigs/application
- create a KIND cluster
- use the KIND cluster to bootstrap an admin cluster
- admin cluster manages the control planes for tenant admin cluster
- tenant cluster further manages tenant user clusters