Understanding Kubernetes and Cloud Native Applications
Kubernetes is an open-source container orchestration engine and also an abstraction layer for managing full stack operations of hosts and containers. From deployment, Scaling, Load Balancing and to rolling updates of containerized applications across multiple hosts within a cluster. Kubernetes make sure that your applications are in the desired state.
Kubernetes 1.8 released on September 28, 2017, with some new features and fulfill the most demanding enterprise environments. There are now new features related to security, stateful applications and extensibility. With Kubernetes 1.7 we can now store secrets in namespaces in a much better way, We ‘ll discuss that below. You can also explore more about what is Kubernetes in detail there.
12 Factor App Methodology and Microservices
In the modern era, software is commonly delivered as a service called web apps, or software as a service. The 12-factor app is a methodology for building software as a service app that –
- Can minimize time and cost for new developers joining the project.
- Offering maximum portability between execution environments.
- Are suitable for deployment on modern cloud platforms.
- Obviating the need for servers and systems administration.
- Minimize divergence between development and production.
- Enabling continuous deployment for maximum agility.
- And can scale up without significant changes to tooling and architecture.
The 12-factor methodology can be applied to apps Continuous Delivery, DevOps Tools written in any programming language, and which use any combination of backing services (database, queue, memory cache etc).
Best practices for building cloud-native applications
Cloud Platform Automation
Microservices Architecture Pattern
DevOps Culture Change
Cloud Reliability Engineering
12-Factors App Principles , Application Patterns
- A 12-factor app should have only one codebase per app, but there will be many deploys of the app. A deploy is a running instance of an app.
- A 12-factor app is always tracked in a version control system. A copy of the revision tracking database is known as a code repository.
- A 12-factor app never relies on the implicit existence of system-wide packages. It declares all dependencies, completely and exactly.
- A 12-factor app should store config in the environment. An app’s config is everything that is likely to vary between deploys (staging, production, developer environments etc).
- A backing service is any service the app consumes over the network as part of its normal operation. The code for a 12-factor app makes no distinction between local and third-party services.
- A deploy of the 12-factor app should be able to swap out a local MySQL database with one managed by a third party without any changes to the app’s code.
Build, Release, Run
- The 12-factor app uses strict separation between the build, release, and run stages. Transformation of code repo into an executable bundle is known as a build. Combination of build stage and current config makes release stage and the run stage runs the app in the execution environment.
- The app is executed in the execution environment as one or more processes. 12-factor processes are stateless and share nothing. Any data that needs to persist must be stored in a stateful backing service typically a database.
- The 12-factor app is completely self-contained and does not rely on runtime injection of a web server into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
- Processes in the 12-factor app will be scale-out via a process model. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a process type.
- The 12-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.
Development / Production Parity
- We have to keep development, staging and production as similar as possible. There should be less time gap, personnel gap and tool gap in development and production. It will help in continuous deployment.
- Treat logs as event streams. A 12-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage log files. Instead, each running process writes its event stream.
- Run admin or management tasks as one-off processes. Admin tasks are such as running one time scripts, running database migrations, running a console to run arbitrary code.
You May also Love To Read Testing Strategies in Microservices Architecture
Beyond the Twelve-Factor App
One codebase, one application
Design, build, release, and run
Configuration, credentials, and code
Other Best Practices for Twelve Factor App
Authentication and authorization
Kubernetes Architecture and Deployment
Managed Kubernetes Cluster operates in master and worker architecture. In which Kubernetes Master get all management tasks and dispatch to appropriate Kubernetes worker node based on given constraints.
- Master Node
- Worker Node
Below I have created two sections so that you can understand better what are the components of the kubernetes architecture and where we exactly using them.
Kubernetes Master Node Architecture
Kube API Server
Kubernetes API server is the center of each and every point of contact to kubernetes cluster. From authentication, authorization, and other operations to kubernetes cluster. API Server store all information in the etc database which is a distributed data store.
Setting up Etcd Cluster
Etcd is a database that stores data in the form of key-values. It also supports Distributed Architecture and High availability with a strong consistency model. Etcd is developed by CoreOS and written in GoLang. Kubernetes components stores all kind of information in etcd like metrics, configurations and other metadata about pods, service, and deployment of the kubernetes cluster.
The kube-controller-manager is a component of Kubernetes Cluster which manages replication and scaling of pods. It always tries to make kubernetes system in the desired state by using kubernetes API server.
There are other controllers also in kubernetes system like
- Replication controller
- Endpoints controller
- Namespace controller
- Service accounts controller
- DaemonSet Controller
- Job Controller
The kube-scheduler is another main component of Kubernetes architecture. The Kube Scheduler check availability, performance, and capacity of kubernetes worker nodes and make plans for creating/destroying of new pods within the cluster so that cluster remains stable from all aspects like performance, capacity, and availability for new pods.
It analyses cluster and reports back to API Server to store all metrics related to cluster resource utilisation, availability, and performance.
It also schedules pods to specified nodes according to submitted manifest for the pod.
Kubernetes Worker Node Architecture
The Kubernetes kubelet is a worker node component of kubernetes architecture responsible for node level pod management.
API server put HTTP requests on kubelet API to executes pods definition from the manifest file on worker nodes and also make sure containers are running and healthy. Kubelet talks directly with container runtimes like docker or RKT.
The kube-proxy is networking component of the Kubernetes Architecture. It runs on each and every node of the Kubernetes Cluster.
- It handles DNS entry for service and pods.
- It provides the hostname, IP address to pods.
- It also forwards traffic from Cluster/Service IP address to specified set of pods.
- Alter IPtables on all nodes so that different pods can talk to each other or outside world.
Docker is an open source container run time developed by docker. To Build, Run, and Share containerized applications. Docker is focused on running a single application in one container and container as an atomic unit of the building block.
- Most Popular
rkt, a security-minded, standards-based container engine – CoreOS
rkt is another container runtime for the containerized application. Rocket is developed by CoreOS and have more focus towards security and follow open standards for building Rocket runtime.
- Pod-native approach
- Pluggable execution environment
Managed Kubernetes Supervisor
Kubernetes supervisor is a lightweight process management system that runs kubelet and container engine in running state.
Kubernetes Logging with Fluentd
Fluentd is an open source data collector for kubernetes cluster logs.
Understanding Basic Kubernetes Concepts
Kubernetes Nodes are the worker nodes in the kubernetes cluster. Kubernetes worker node can be a virtual machine or bare metal server.
Node has all the required services to run any kind of pods. Node is also managed by the master node of the kubernetes cluster.
Following are the few services of Nodes
A container is a standalone, executable package of a piece of software that includes everything like code, run time, libraries, configuration.
1. Supports both Linux and Windows-based apps
2. Independent of the underlying infrastructure.
Docker and CoreOS are the main leaders in containers race.
Pods are the smallest unit of Kubernetes architecture. It can have more than 1 containers in a single pod. A pod is modelled as a group of Docker containers with shared namespaces and shared volumes.
A Deployment is JSON or YAML file in which we declare Pods and Replica Set definitions. We just need to describe the desired state in a Deployment object, and the Deployment controller will change the actual state to the desired state at a controlled rate for you.
- Create new resources
- Update existing resources
Managed Kubernetes Service YAML/JSON
A Kubernetes Service definition is also defined in YAML or JSON format. It creates a logical set of pods and creates policies for each set of pods that what type of ports and what type of IP address will be assigned. The Service identifies set of target Pods by using Label Selector.
Example: – service.yml
Kubernetes Replication Controller
A Replication Controller is a controller who ensures that a specified number of pod “replicas” should be in running state.
- Pods should be running
- Pods should be in desired replica count.
- Manage pods on all worker nodes of the Managed Kubernetes cluster.
Example :- rc.yml
Labels are key/value pairs. It can be added any kubernetes objects, such as pods, service, deployments. Labels are very simple to use in the kubernetes configuration file.
Below mentioned code snippet of labels
Because labels provide meaningful and relevant information to operations as well as developers teams. Labels are very helpful when we want to roll update/restore application in a specific environment only. Labels can work as filter values for kubernetes objects. Labels can be attached to kubernetes objects at any time and can also be modified at any time.
Non-identifying information should be recorded using annotations.
Container Registry is a private or public online storage that stores all container images and let us distribute them.There are so many container registries in the market.
Deploying Microservices Application with Kubernetes
Kubernetes is a collection of APIs which interacts with computer, network and storage.
There are so many ways to interact with the Managed Kubernetes cluster.
Direct Kubernetes API is available to do all tasks on the kubernetes cluster from deployment to maintenance of anything inside the kubernetes cluster.
Kubernetes Dashboard is simple and intuitive for daily tasks. We can also manage our kubernetes cluster from the kubernetes dashboard.
Kubernetes CLI is also known as kubectl. It is written in GoLang. It is the most used tool to interact with either local or remote kubernetes cluster.
Continuous Delivery for Application on Kubernetes
Below mentioned deployment guides can be used to most of the popular language application on kubernetes.
- Continuous Delivery for Python Application on Kubernetes
- Continuous Delivery for NodeJS on Kubernetes
- Continuous Delivery for GoLang on Kubernetes
- Continuous Delivery for Java Applciation on Kubernetes
- Continuous Delivery for Scala Application on Kubernetes
- Continuous Delivery for ReactJS on Kubernetes
- Continuous Delivery for Kotlin on Kubernetes
- Continuous Delivery for .Net on Kubernetes
- Continuous Delivery for Ruby on Rails on Kubernetes
Kubernetes Monitoring: Best Practices, Methods
Kubernetes gives us an easier and managing infrastructure by creating many levels of abstractions such as node, pods, replication controllers, services. Nowadays due to this, we don’t worry about where applications are running or related to its resources to work properly. But in order to ensure good performance, we need to monitor our deployed applications and containers.
There are many tools like cAdvisor, Grafana available to monitor the kubernetes environment with visualization. Nowadays Grafana is booming in the industry to monitor kubernetes environment.
Using cAdvisor to Monitor Kubernetes
cAdvisor is an open source tool to monitor kubernetes resource usage and performance. cAdvisor discovers all the deployed containers in the kubernetes nodes and collects the information like CPU, Memory, Network, file system. cAdvisor provides us with a visualise monitoring web dashboard.
Monitoring Kubernetes Using Grafana
Grafana is an open source metrics analytics and visualization suite. Grafana commonly used for visualizing time series data for application analytics. In Grafana, we need a time series database like “influxdb” and a cluster-wide aggregator of monitoring and event data like heapster.
There are 4 steps to get information of kubernetes and visualise it to grafana dashboard.
Step 1: Hepster collects the cluster-wide data from the kubernetes environment.
Step 2: After collecting the data hepster provide it to influxdb.
Step3: And now grafana execute the metrics through the influxdb client to collect required data.
Step4: After getting required data grafana visualise the same in graphs.
You can create a custom dashboard on Grafana as per your requirement.
Enterprise Kubernetes Solutions & Production Grade Cluster
Workloads API GA in Kubernetes 1.9
Kubernetes 1.9 introduced General Availability (GA) of the apps/v1 Workloads API, which is now enabled by default. The Apps Workloads API groups the DaemonSet, Deployment, ReplicaSet, and StatefulSet APIs together to form the foundation for long-running stateless and stateful workloads in Kubernetes.
Deployment and ReplicaSet, two of the most commonly used objects in Kubernetes, are now stabilized after more than a year of real-world use and feedback.
Windows Support (Beta) For Kubernetes 1.9
Kubernetes 1.9 introduces SIG-Windows, Support for running Windows workloads.
Storage Enhancements in Kubernetes 1.9
Kubernetes 1.9 introduces an alpha implementation of the Container Storage Interface (CSI), which will make installing new volume plugins as easy as deploying a pod, and enable third-party storage providers to develop their solutions without the need to add to the core Kubernetes codebase.
Compressive Approach To Kubernetes
Kubernetes is an open-source container for managing full stack operations and containers. Discover how XenonStack’s Managed Kubernetes Consulting Solutions For Enterprises and Startups can help them for Migrating to Cloud-Native Application Architectures means re-platforming, re-hosting, recoding, rearchitecting, re-engineering, interoperability, of the legacy Software application for current business needs. Application Modernization services enable the migration of monolithic applications to new Microservices architecture. Deploy, Manager and Monitor your Big Data Stack Infrastructure on Kubernetes. Run large scale multi-tenant Hadoop Clusters and Spark Jobs on Kubernetes with proper Resource utilization and Security. Please review the below steps:
Explore more about “Application Migration and Modernization Solutions”
Discover how to “Deploy Cloud Native Application on Kubernetes”
Get in Touch with us for ” Kubernetes Consulting Services and Solutions”
How useful was this post?