5 Easy Steps To Create a Kubernetes Cluster Using Kubeadm

• June 28, 2019

  |

  
  

  Yobitel Communications

  
  

  If you want to manually create the cluster (i.e., without GKE) using kubeadm, then this document may help you to do it. Before moving into the procedure it is good to have knowledge on kubeadm.

  
  

  Prerequisites:

  
  

  OS: Ubuntu version 16.04 or higher

  Minimum Memory required: For master node - 2 CPU's, 8GB memory

                                               For each worker node - 1 CPU's, 4GB memory

  
  

  Let us look into the steps for cluster creation using kubeadm

  
  

  Step 1: Docker Installation

  
  

  Create the Instances in the GCE , It should be at least one master node and  two or more worker nodes. Follow these steps for all the nodes.

  
  

  Docker installation is the primary steps in the cluster creation, so follow the below steps for all the nodes you created. Otherwise you can also look into the official docker documentation for docker installation.

  1. $ sudo apt-get update -y
  2. $ sudo apt-get install -qy docker.io

  Check whether docker got properly installed or not using docker --version command 

  
  

  Step 2: Install Kubeadm

  • Get Kubernetes repo key

   $ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add

  • Add Kubernetes repository to manifests

  $ sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

  • Install Kubeadm 

  $ sudo apt install kubeadm

  
  

  Check kubeadm version and make sure it is properly installed or not.

  
  

  $ kubeadm version 

  
  

  Step 3: Create the cluster

  
  

  It is possible to configure kubeadm init with a configuration file instead of command line flags, and some more advanced features may only be available as configuration file options. This file is passed in the --config option.

  
  

  On master node:

  
  

  Initialize the kubeadm

  
  

  $ sudo kubeadm init [option]

  
  

  Options:

  •     --pod-network-cidr=10.244.0.0/16
  •     --config=/root/kubeadm-config.yaml
  •     --cert-dir

  

  
  

  Copy and execute kubectl config file

  
  

  $ mkdir -p $HOME/.kube

  $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

  $ sudo chown $(id -u):$(id -g) $HOME/.kube/config

  
  Step 4: Join worker node

  
  

  To join worker nodes to the master node, run the below command separately on each worker node

  
  

  As a root user 

  
  

  $ kubeadm join 10.156.0.18:6443 --token ow15j0.kz12nltctqeowkiy \

  >     --discovery-token-ca-cert-hash sha256:a7024eacb754a01721f28cedc52e92427a83225db0f800d1bfb9117f2832602c

  

  To check whether all the pods are active and running, run the following command on the master node.

  
  

  $ kubectl get nodes

  

  
  

  Step 5: Troubleshooting

  • When you are initializing kubeadm with cidr, then If you get pods status as not ready  then run the following code in master node

  $ sudo kubectl  apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

  • If you are doing kubeadm init with config file then sample template of the file is shown below.

  
  

  Kubeadm-config.yaml sample template

  

  
  

  
  

  
  

   You can access the yaml file here.
  

  
  

  Tear down:

  
  

  To tear down the kubeadm, run these commands on the master node

  
  

  $ kubectl drain <node name> — delete-local-data — force — ignore-daemonsets

  
  

  $ kubectl delete node <node name>

  
  

  Then, on the node being removed, reset all kubeadm installed state:

  
  

  $ kubeadm reset

  
  

  
  

  
  

  
  
  

Time To Travel with Hyper-Converged Cloud-Native Containerized Application Services

The fundamentals of Cloud-native have been described as container packaging, dynamic application development, and a Microservices-oriented Serverlessarchitecture. Technologies are used to develop applications built as services, packaged in containers, deployed as microservices and managed on elastic infrastructure through agile DevOps Continuous Development workflows. The main motive is to improve speed, scalability and finally margin. Truly cloud-based organizations have started to differentiate themselves as being ‘cloud-native.’ The main tools and services included in the cloud-native services are:

• Infrastructure Services
• Automation/Orchestration
• Containerization
• Microservices Architecture
• Serverless
• Containerized Application Service​

• 
  
  
• Currently, enterprise applications are built using modern cloud technologies and it is hosted and managed in the cloud end-to-end, where it includes writing code, testing, deploying it and operating those applications, all in the cloud. Even though having all these advantages, it also includes disadvantages:
  • We are talking about adopting digital transformation via cloud, containers and even serverless mechanism.
  • Also fascinating the rich user experience with microservices and with continuous delivery to continuous deployment.
  • But, other than understanding and adopting, it is always a pain for an enterprise customer to prepare and execute the existing advanced bottom-lined infrastructure for their applications to reside and to maintain.
  Here, in the years of evolution, every enterprise customer loves to adopt click and go application and forget worrying either it’s in cloud or container, do we follow canary or blue-green deployments, green field or brown field, improving continuous delivery application life-cycle management, version upgrades, packaging the applications, deployment practices and standards, governance policies, overhead in maintenance and automation requirements with a shooting price for various unidentified infrastructure and application billings. There are many reasons why one to migrate towards cloud-native service and few are listed here. Check out our other post regarding cloud-native services here.
  
  

  1. Reduced Cost through Containerization against Cloud Platforms:

  Containers make it easy to manage and secure applications independently of the infrastructure that supports them. The industry is now consolidating around Kubernetes for the management of these containers at scale. As an open source platform, Kubernetes enjoys industry-wide support and is the standard for managing resources in the cloud. Cloud-native applications fully benefit from containerization. Enhanced cloud-native capabilities such as Serverless let you run dynamic workloads and pay-per-use compute time in milliseconds. This is the ultimate flexibility in pricing enabled by cloud-native.
  
  

  2. Build More Reliable Systems:

  In the traditional system, downtime used to be accepted as normal and achieving fault tolerance was hard and expensive. With modern cloud-native approaches like microservices architecture and Kubernetes in the cloud, you can more easily build applications to be fault tolerant with resiliency and self-healing built in. Because of this design, even when failures happen you can easily isolate the impact of the incident so it doesn’t take down the entire application. Instead of servers and monolithic applications, cloud-native microservices helps you achieve higher uptime and thus further improve the user experience.
  
  
  3. Ease of Management:
  Cloud-native also has many options to make infrastructure management effortless. It began with PaaS platforms like Google App Engine about a decade ago and has expanded to include serverless platforms like Spotinst and AWS Lambda. Serverless computing platforms let you upload code in the form of functions and the platform runs those functions for you so you don’t have to worry about provisioning cloud instances, configuring networking, or allocating sufficient storage. Serverless takes care of it all.
  
  

  4. Achieve Application Resilience:

  The disadvantages of monolithic applications are overcome by Microservices. The main advantage of microservice is that even if a single server fails, its neighboring services can function normally. This would affect the user experience to an extent but is better than rendering the entire application unusable. Even in the rare case of a failed host, you can replicate a backup instance in the cloud, which is much faster than procuring new hardware. Finally, cloud vendors provide multiple availability zones and they increase the performance of every region you serve by isolating the faults to particular regions. The cloud enables reliability in a way that’s not possible with traditional on-premise hardware.
  
  

  5. Do Not Compromise on Monitoring and Security:

  As a system scales it’s easy to compromise on monitoring and security. Monitoring and security are fundamentally different from cloud-native applications. Rather than rely on a single monitoring tool, you will likely need to take a best-of-breed approach to monitor by using a combination of vendor-provided open source monitoring tools like Prometheus. Security in the cloud requires adequate encryption of data in transit and at rest. The cloud vendors provide encryption services for this purpose. Additionally, open source tools like Calico are enabling networking and network policy in Kubernetes clusters across the cloud. Though monitoring and security are more complex and challenging for cloud-native applications, when done right they provide a level of visibility and confidence that is unheard of with traditional monolithic applications running on-premise.
  
  
  6. Containerized Application Services:
  Containerization helps the development team to move fast, deploy software efficiently, and operate at an unprecedented scale. The main uses of containerized applications are listed below:
  • Containerized applications like Kubecharts, ChartMuseum are the User Interfaces for deploying and managing applications in Kubernetes clusters.
  • Chartmuseum is an open source helm chart repository server with support for cloud storage back ends, including Google Cloud Storage, Amazon S3, etc.
  • Harbor is a containerized application which is mainly used for the version upgrade management and also to manage and serve the container images in a secure environment.
  • Istio is used to provide security to pods and containers, which are secured to uncertain scalability levels.
  • Individual application components can be stored in JFrog Artifactory so that later they can be assembled into a full product -  thus allowing a build to be broken in smaller chunks, making more efficient use of resources, reducing build times, better tracking of binary debug databases, etc.
  
  
  7. Enterprise Mesh for Cloud-native Stacks:
  The concept of the service mesh as a separate layer is tied to the rise of the cloud-native application. In the cloud-native model, a single application might consist of hundreds of services; each service might have thousands of instances, and each of those instances might be constantly-changing as they are dynamically scheduled an orchestrator like Kubernetes. Managing it is vital to ensuring end-to-end performance and reliability. Communication within clusters is a solved issue, but communication across clusters requires more design and operational overhead. The communication between these microservices in a cluster can be enhanced by a service mesh. Service mesh-like Istio, envoy can make multi-cluster communication painless.
  
  
  8. Schedulers:
  The Kubernetes Scheduler is a core component of Kubernetes: After a user or a controller creates a Pod, the Kubernetes Scheduler, monitoring the Object Store for unassigned Pods, will assign the Pod to a Node. Then, the Kubelet, monitoring the Object Store for assigned Pods, will execute the Pod. example are etcd, IBM spectrum LSF (which is used in High-Performance computers). When the schedulers are applied to the file system, file share access, prioritization, job placement, rich policy control, job dependencies, singularity Integrator can be achieved.
  
  
  Summary:
  Cloud-Native is a powerful, promising technology. Enterprises are understandably eager to get there as fast as they can. But reaping the full benefit of the cloud means first taking care to build a solid foundation based on the principles of Cloud-Native architecture.
  The key points being cloud-native are:
  • Cloud-native workloads are slowly gaining momentum. Today, 18% of organizations have more than half of workloads cloud-native. Large enterprises are waiting to adapt existing applications to cloud environments until the end of the useful life of existing data center equipment.
  • High Throughput computing.
  • Data Analytics allows you to view statistical information about the unstructured, data in your cloud environment. With this information, you can quickly assess the current state of your data, take actionable steps to retrieve valuable storage space, and mitigate the risk of compliance-related issues.
  • A cloud-native application consists of discrete, reusable components known as microservices that are designed to integrate into any cloud environment.
  
  
  Solution:
  • Cloud-Native SaaS Multi-Cloud Containerized Serverless Application Platform Services and Business Intelligence Mechanism with our redefined cloud-native stacks - Kubernetes Charts and Yobibyte.
  • Users have an amazing choice of deploying the applications on our Yobibyte platform with the customized Cloud-Native Application repository - Kubecharts (A Kubernetes application package medium), to deploy in minutes and to achieve full-fledged digital transformation.  
  • Our Kubecharts repository provides 1000+ enterprise free and licensed containerized serverless application packages can deploy in multi-cloud environments to the enterprise users.  
  • It enables no vendor-locking, any time deploy and no term locking for your containerized application and provides pay-as-you-go (PAYG) mode.
  
  
  For more details about cloud-native services log into our website Yobitel communications.
  
  Please refer more for Cloud-native 10 key attributes to choose Microservices over Monolithic.