Understanding Kubernetes Objects:
Prakash Kumar
Kubernetes objects are represented in the Kubernetes API, and how you can express them in .yaml format.
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
• What containerized applications are running (and on which nodes)
• The resources available to those applications
• The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
A Kubernetes object is a “record of intent”–once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
To work with Kubernetes objects–whether to create, modify, or delete them–you’ll need to use the Kubernetes API. When you use the kubectl command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the Client Libraries.
vi deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 #tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
In the .yaml file for the Kubernetes object you want to create, you’ll need to set values for the following fields:
• apiVersion - Which version of the Kubernetes API you’re using to create this object
• kind - What kind of object you want to create
• metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace
• The selector field defines how the Deployment finds which Pods to manage. In this case, you simply select a label that is defined in the Pod template (app: nginx).
• matchLabels is a map of {key,value} pairs
The template field contains the following sub-fields:
• The Pods are labeled app: nginx using the labels field.
• The Pod template’s specification, or .template.spec field, indicates that the Pods run one container, nginx, which runs the nginx Docker Hub image at version 1.7.9.
• Create one container and name it nginx using the name field.
• Open port 80 so that the container can send and accept traffic
Create your deployment:
kubectl apply –f deployment.yaml
Check your deployment:
kubectl get deployment
Check your status:
kubectl rollout status deployment <deployment name>
Check assigned pod labels:
kubectl get pods –show-labels
Pod-template-hash label:
The name of the ReplicaSet is always formatted as [DEPLOYMENT-NAME]-[RANDOM-STRING].
The random string is randomly generated and uses the pod-template-hash as a seed.
The pod-template-hash label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
This label ensures that child ReplicaSets of a Deployment do not overlap
Replica sets, Replication Controller, Deployment:
• Replica set is new set of replications. Earlier we had replication controller which does not support rolling update commands,
• Now, you want to use rolling update functionality pleat consider using deployment
• Rolling update commands is imperative (by running commands) whereas deployments are declarative (by writing manifests and using kubectl apply), so kubernetes recommend rolling out commands thought deployment.
Imperative Configuration example
kubectl run myapp --image myrepo:mytag --replicas 2
Declarative Configuration example:
Write manifest file then (above example deployment.yml)
kubectl apply -f deployment.yml
• replica set can be used independently.
vi replicasets.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
#modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
kubectl create -f replicasets.yml
kubectl get rs
kubectl describe rs frontend
• During a rolling update, a new ReplicaSets will be created and progressively scaled out to the desired number of replicas, while the old one is scaled in to zero
• In deployment you don’t need to be worried about replica sets that alert can be used in deployment
Isolating Pods from a ReplicaSet
You can remove Pods from a ReplicaSet by changing their labels
Syntax: kubectl label --overwrite pods <pod name> <label name>=<label value>
kubectl label --overwrite pods <pod name> tier=frontlaa
How to assign new label to a pod:
kubectl label pods <pod name> new-label=awesome
How to delete a pod with specific label
kubectl delete pods -l new-label=awesome
Horizontal Pod Autoscaling
With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization
(we also can set some other metrics such memory)
The resource determines the behavior of the controller. The controller periodically adjusts the number of replicas in a replication controller or deployment to match the observed average CPU utilization to the target specified by user. (with a default value of 30 seconds)
vi horizontalscaling.yml
apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleRef:
kind: ReplicationController
name: php-apache
namespace: default
subresource: scale
minReplicas: 1
maxReplicas: 10
cpuUtilization:
targetPercentage: 50
#kubernetes #docker #microservices #DevOps #cicd #aws #azure #gcp
