aster.cloud aster.cloud
  • /
  • Platforms
    • Public Cloud
    • On-Premise
    • Hybrid Cloud
    • Data
  • Architecture
    • Design
    • Solutions
    • Enterprise
  • Engineering
    • Automation
    • Software Engineering
    • Project Management
    • DevOps
  • Programming
  • Tools
  • About
aster.cloud aster.cloud
  • /
  • Platforms
    • Public Cloud
    • On-Premise
    • Hybrid Cloud
    • Data
  • Architecture
    • Design
    • Solutions
    • Enterprise
  • Engineering
    • Automation
    • Software Engineering
    • Project Management
    • DevOps
  • Programming
  • Tools
  • About
  • Platforms

Decoding The Self-Healing Kubernetes: Step By Step

  • relay
  • May 28, 2020
  • 5 minute read

Business application that fails to operate 24/7 would be considered inefficient in the market. The idea is that applications run uninterrupted irrespective of a technical glitch, feature update, or a natural disaster. In today’s heterogeneous environment where infrastructure is intricately layered, a continuous workflow of application is possible via self-healing.

Captain America asked Bruce Banner in Avengers to get angry to transform into ‘The Hulk’. Bruce replied, “That’s my secret Captain. I’m always angry.”You must have understood the analogy here. Let’s simplify – Kubernetes will self-heal organically, whenever the system is affected.

Kubernetes, which is a container orchestration tool, facilitates the smooth working of the application by abstracting machines physically. Moreover, the pods and containers in Kubernetes can self-heal.

Kubernetes’s self-healing property ensures that the clusters always function at the optimal state. Kubernetes can self-detect two types of object – podstatus and containerstatus. Kubernetes’s orchestration capabilities can monitor and replace unhealthy container as per the desired configuration. Likewise, Kubernetes can fix pods, which are the smallest units encompassing single or multiple containers.

The three container states include

01. Waiting – created but not running. A container, which is in a waiting stage, will still run operations like pulling images or applying secrets, etc. To check the Waiting pod status, use the below command.

kubectl describe pod [POD_NAME]

Along with this state, a message and reason about the state are displayed to provide more information.

... 
State: Waiting 
Reason: ErrImagePull 
...

02. Running Pods – containers that are running without issues. The following command is executed before the pod enters the Running state.

postStart

Running pods will display the time of the entrance of the container.

...   
State:          Running    
Started:      Wed, 30 Jan 2019 16:46:38 +0530 
...

03. Terminated Pods – container, which fails or completes its execution; stands terminated. The following command is executed before the pod is moved to Terminated.

prestop

Terminated pods will display the time of the entrance of the container.

…
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Wed, 30 Jan 2019 11:45:26 +0530
Finished:     Wed, 30 Jan 2019 11:45:26 +0530
…

Kubernetes’ self-healing Concepts – pod’s phase, probes, and restart policy.

The pod phase in Kubernetes offers insight into the pod’s placement. We can have

  • Pending Pods – created but not running
  • Running Pods – runs all the containers
  • Succeeded Pods – successfully completed container lifecycle
  • Failed Pods – minimum one container failed and all container terminated
  • Unknown Pods
Read More  Spot By NetApp Delivers Availability, Automation, And Cost Savings For Cloud Workloads With Microsoft Azure Spot Virtual Machines

Kubernetes execute liveliness and readiness probes for the Pods to check if they function as per the desired state. The liveliness probe will check a container for its running status. If a container fails the probe, Kubernetes will terminate it and create a new container in accordance with the restart policy. The readiness probe will check a container for its service request serving capabilities. If a container fails the probe, then Kubernetes will remove the IP address of the related pod.

Liveliness probe example.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # when "host" is not defined, "PodIP" will be used
        # host: my-host
        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

The probes include

  • ExecAction – to execute commands in containers.
  • TCPSocketAction – to implement a TCP check w.r.t to the IP address of a container.
  • HTTPGetAction – to implement a HTTP Get check w.r.t to the IP address of a container.

Each probe gives one of three results:

  • Success: The Container passed the diagnostic.
  • Failure: The Container failed the diagnostic.
  • Unknown: The diagnostic failed, so no action should be taken.

Demo description of Self-Healing Kubernetes – Example 1

We need to set the code replication to trigger the self-healing capability of Kubernetes.

Let’s see an example of the Nginx file.

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-deployment-sample
spec:
  selector:
    matchLabels:
      app: nginx
  replicas:4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

In the above code, we see that the total number of pods across the cluster must be 4.

Read More  Improve Your App Mileage With Android For Cars App Library

Let’s now deploy the file.

kubectl apply nginx-deployment-sample

Let’s list the pods, using

kubectl get pods -l app=nginx

Here is the output.

As you see above, we have created 4 pods.

Let’s delete one of the pods.

kubectl delete nginx-deployment-test-83586599-r299i

The pod is now deleted. We get the following output

pod "deployment nginx-deployment-test-83586599-r299i" deleted

Now again, list the pods.

kubectl get pods -l app=nginx

We get the following output.

We have 4 pods again, despite deleting one.

Kubernetes has self-healed to create a new node and maintain the count to 4.

Demo description of Self-Healing Kubernetes – Example 2

Get pod details

$ kubectl get pods -o wide

Get first nginx pod and delete it – one of the nginx pods should be in ‘Terminating’ status

$ NGINX_POD=$(kubectl get pods -l app=nginx --output=jsonpath="{.items[0].metadata.name}")
$ kubectl delete pod $NGINX_POD; kubectl get pods -l app=nginx -o wide
$ sleep 10

Get pod details – one nginx pod should be freshly started

$ kubectl get pods -l app=nginx -o wide

Get deployment details and check the events for recent changes

$ kubectl describe deployment nginx-deployment

Halt one of the nodes (node2)

$ vagrant halt node2$ sleep 30

Get node details – node2 Status=NotReady

$ kubectl get nodes

Get pod details – everything looks fine – you need to wait 5 minutes

$ kubectl get pods -o wide

Pod will not be evicted until it is 5 minutes old – (see Tolerations in ‘describe pod’ ). It prevents Kubernetes to spin up the new containers when it is not necessary

$ NGINX_POD=$(kubectl get pods -l app=nginx --
output=jsonpath="{.items[0].metadata.name}")
$ kubectl describe pod $NGINX_POD | grep -A1 Tolerations

Sleeping for 5 minutes

$ sleep 300

Get pods details – Status=Unknown/NodeLost and new container was started

$ kubectl get pods -o wide

Get depoyment details – again AVAILABLE=3/3

$ kubectl get deployments -o wide

Power on the node2 node

$ vagrant up node2
$ sleep 70

Get node details – node2 should be Ready again

$ kubectl get nodes

Get pods details – ‘Unknown’ pods were removed

$ kubectl get pods -o wide

**Source: GitHub. Author: Petr Ruzicka

Conclusion

Kubernetes can self-heal applications and containers, but what about healing itself when the nodes are down? For Kubernetes to continue self-healing, it needs a dedicated set of infrastructure, with access to self-healing nodes all the time. The infrastructure must be driven by automation and powered by predictive analytics to preempt and fix issues beforehand. The bottom line is that at any given point in time, the infrastructure nodes should maintain the required count for uninterrupted services.

Read More  Cloudflare’s Data Localization Suite Gives Global Companies The Tools They Need To Control Data Wherever They Do Business

 

Guest post originally published on the Msys Technology blog by Atul Jadhav

Source: CNCF blog 

relay

Related Topics
  • Cloud Native Computing Foundation
  • CNCF
  • GitHub
  • Kubernetes
  • Self-Healing Kubernetes
You May Also Like
View Post
  • People
  • Platforms
  • Technology

Women’s History Month: Celebrating The Success Of Women Founders: Schoolio

  • March 14, 2023
View Post
  • Platforms
  • Technology

Cloudflare Integrates With Atlassian, Microsoft, And Sumo Logic To Make Zero Trust Security Easy For Businesses

  • March 14, 2023
View Post
  • Platforms

Oxford Quantum Circuits Installing Quantum Computer in Equinix IBX® Data Center With Plans To Open Access to Businesses Globally

  • March 14, 2023
View Post
  • Platforms
  • Research
  • Solutions

Salk Institute Leverages Google Cloud For Brain Research—And Launches Their Transformation To The Cloud

  • March 6, 2023
View Post
  • Platforms
  • Technology

CrowdStrike And Dell Technologies Join Forces To Transform Commercial PC Cybersecurity

  • March 6, 2023
View Post
  • Platforms
  • Tools

3 Microsoft Azure AI Product Features That Accelerate Language Learning

  • March 3, 2023
View Post
  • Platforms
  • Solutions
  • Technology

Equinix To Back Five New Solar Farms In Spain

  • February 28, 2023
View Post
  • Data
  • People
  • Platforms

Meet Our Data Champions: Emily Bobis, Driving Road Intelligence In Australia

  • February 24, 2023

Stay Connected!
LATEST
  • 1
    Monitor Kubernetes Cloud Costs With Open Source Tools
    • March 20, 2023
  • 2
    What Is An Edge-Native Application?
    • March 20, 2023
  • 3
    Eclipse Java Downloads Skyrocket
    • March 19, 2023
  • 4
    How To Use Bash
    • March 17, 2023
  • 5
    Why Is Your Multicloud So Slow?
    • March 17, 2023
  • 6
    The Benefits And Core Processes Of Data Wrangling
    • March 17, 2023
  • 7
    We Cannot Even Agree On Dates…
    • March 16, 2023
  • 8
    Financial Crisis: It’s A Game & We’re All Being Played
    • March 16, 2023
  • 9
    Ballerina: A Programming Language For The Cloud
    • March 16, 2023
  • 10
    Own Your Cloud With NextcloudPi On The Raspberry Pi
    • March 16, 2023
about
Hello World!

We are aster.cloud. We’re created by programmers for programmers.

Our site aims to provide guides, programming tips, reviews, and interesting materials for tech people and those who want to learn in general.

We would like to hear from you.

If you have any feedback, enquiries, or sponsorship request, kindly reach out to us at:

[email protected]
Most Popular
  • 1
    Oxford Quantum Circuits Installing Quantum Computer in Equinix IBX® Data Center With Plans To Open Access to Businesses Globally
    • March 14, 2023
  • 2
    The Adoptium Working Group Reports Significant Momentum for Open Source Java in 2023
    • March 14, 2023
  • 3
    Cloudflare Integrates With Atlassian, Microsoft, And Sumo Logic To Make Zero Trust Security Easy For Businesses
    • March 14, 2023
  • 4
    Cloudflare Uses The Power Of Its Global Network To Identify The Top 50 Most Impersonated Brands And Protect Zero Trust Customers From Phishing Scams
    • March 13, 2023
  • 5
    Open Source Software Leader The Eclipse Foundation Previews Its Showcase At Embedded World 2023
    • March 8, 2023
  • /
  • Platforms
  • Architecture
  • Engineering
  • Programming
  • Tools
  • About

Input your search keywords and press Enter.