Kubernetes Objects
- Every k8s object can be describe using .yaml (specification) or json when using with rest api and passed accross to kube-api server via kubectl or k8s REST API. The cluster responds back with status
- While describing object spec, we will have some required fields
- apiVersion: Which version of k8s api are you using to create this object
- kind: what kind of k8s object do you want to create
- metadata: Data which is helpful in uniquely identifying the object, here we will be have name, UID and optional namespace
- spec: What is your desired state
K8s Workloads
- Workload is an application running on k8s cluster.
- A Pod has a defined lifecycle. If the pod fails, we need to create the new pod running the same application, K8s has workload resources which can maintain desired state of pods
- Workload resources are
- Deployments
- Replica Sets
- Stateful Sets
- Daemon Sets
- Job and Cron Job
The Pod Manifest
- Pods are described in a Pod Manifest which is a text-file representation of k8s API Object.
- Creating a Pod in a imperative kubectl run command

- Creating a Pod using a manifest file
- Refer Here for the pod manifest

- Accessing your pod:

- Logs information of your pod:

- Running commands in your container with exec
Exercise: Create a pod manifest for spring petclinic by using api reference Refer Here - Refer Here for the spc solution
- Top commands in k8s cluster

- Resource Management:
- Resource Requests for Minimum required resources and maximum limits Refer Here
- Refer Here for resource limits in a pod.
- Refer Here for multi container pod
K8s API Groups
- K8s groups api’s as api groups.
- The major purpose is to extend k8s
- Refer Here for api groups
- To use resources from api groups the naming convention is
<GROUP_NAME>/<VERSION>in yaml file- batch/v1
- extensions/v1beta1
- rbac.authorization.k8s.io/v1
- To use resource from api groups in the REST api, convention is
/apis/<GROUP_NAME>/<VERSION>- /apis/batch/v1
- /apis/extensions/v1beta1
- /apis/rbac.authorization.k8s.io/v1
- If the resources are part of core group we can directly write the version
apiVersion: v1
Replica Set
-
Replica Set will ensure that the number of replicas specified in the spec is maintained by k8s cluster.

-
K8s will try to maintain the desired state which is number of replicas. If some pod gets deleted/crashed etc, k8s will create one more pod to maintain the desired state.

-
Pods might be alloacated on different cluster nodes.
-
So lets create a replica set with 2 replicas for game of life. Refer Here for the changeset
-
Now lets add selector for the labels

-
apply the replicaset and explore

-
Now lets shutdown one node

-
Lets configure replicaset for autoscaling using imperative commands

-
Next Steps:
- How do i access the application in the case of multiple replicas
- How do i deploy the new version of my application without having a downtime
- How about the storage problem
- How is k8s networking working.
