How to write manifest files
ApiVersioning
- k8s api server exposes k8s Workloads as Resources
- K8s maintains api Versions for them
- K8s has api Versioning scheme Refer Here
- API Versioning:
- alpha:
v1alpha
- beta:
v1beta
- stable:
v1 or v2
- K8s groups multiple resources into api Groups
apiVersion: <group>/<version>
# if the group name is core write version directly
- Example:
- group: core
- Resource: Pod
- version: v1
apiVersion: v1
kind: Pod
- Example 2:
- group: apps
- version: v1
- Resource: Deployment
apiVersion: apps/v1
kind: Deployment
-
Lets write first two fields of multiple resources using k8s 1.35 api reference
-
Namespace
apiVersion: v1
kind: Namespace
apiVersion: v1
kind: PersistentVolumeClaim
apiVersion: apps/v1
kind: StatefulSet
metadata
- This contains information about the object which we are going to create
- on major note we will fill
- name
- labels
- annonatations
- For today lets focus only on names
Example 1
- Lets write a spec for a pod with name example-1
apiVersion: v1
kind: Pod
metadata:
name: example-1
- Lets create a deployment with a name deploy-1
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-1
Spec
- This is field for around 95 % of what we do
- This is where we provide our desired state
- To fill this field we need to understand the functionality
Status
- This is filled by k8s not by use
Pod in k8s
Filling pod specs
Example 1
- Lets write a manifest for k8s pod which has a httpd image based container
---
apiVersion: v1
kind: Pod
metadata:
name: example-1
spec:
containers:
- image: httpd
name: web
kubectl apply -f <filepath>
kubectl delete -f <filepath>
kubectl get pods
kubectl get pods -o wide
kubectl describe pod <name>
-
Commands:
- apply
- delete
- describe
- get
-
In k8s what we create is referred as objects
- kubectl has interesting command
kubectl api-resources
- Exercise:
- Write a spec to create a mysql container and pass environment variable for root password
- Write a spec to create a nginx container and fill the port information.