Google Cloud Kubernetes Engine Cluster


Clusters in GKE


 

Anatomy of a Kubernetes cluster


  • The most simple way to think of Kubernetes is just like any other cluster.
  • It's a collection of computers joined together to perform some function.
  • A typical Kubernetes cluster will contain one or more masters and one or more nodes.
  • Nodes are just communal gang variety computers.
  • These can be large physical servers or even raspberry pies.


In the case of Google Kubernetes engine, they are virtual machines running in Google compute engine.

Kubernetes Master:

  • Masters run several components that form what's called the control plane.
  • This means they're in charge of controlling the cluster.
  • They make decisions about the cluster.
  • Such as where to schedule certain workloads.
  • The master is responsible for the state of a cluster.
  • It's constantly watching everything to make sure the state is as it should be.

Components of a Kubernetes Master.

  • API Server:
    • The API Server is the front end of the control plane it exposes the API for all the master functions.
    • Every time you communicate with the master or anything else communicates with the master It would be through this API.
    • Most of the time you'll use google cloud counsel or command line tool but in the background it's always talking to this API.
    • Once a cluster is up and running your day to day interaction is just going to be with that API Server. 
    • And with GKE there is a good reason you don't need to worry too much about this individual components.
  • etcd
    • etcd  is Kubernetes own database.
    • Storing all of it's configuration in state.
    • We call it a database but really etcd is just a key value store.
    • It is very well known one that is designed for scale and higher availability.
  • Scheduler
    • The Scheduler is responsible for scheduling work loads.
    • That means is when you want to deploy a container the scheduler will pick a node to run that container on.
    • The node it picks can be affected by all kinds of factors such as the current load on each available node.
    • The requirements of your container and some other customizable constraints.
  • Cloud Controller Manager
    • The Cloud Controller Manager, is what allows Kubernetes to work with cloud platforms.
    • Kubernetes itself is an open source project  with contributions from lots of large companies
    • not just Google So it doesn't natively contain functionality for google cloud only. 
    • This manager is responsible for handling things like networking and load balancing as they translate to the product and services of a particular cloud platform.
  • Kube Controller Manager
    • Its job is to manage a handful of controllers in the cluster.
    • The controllers themselves look after things like nodes and a few other objects.


Kubernetes Node

  • Nodes run components that form the runtime environment.
  • There basically the workers with a container runtime.
  • In this node computers, provide the resources of the cluster.
  • All of the CPU and RAM can be used to run containers
  • When you deploy a container in Kubernetes the master will pick a node to run it on. 
  • These are going to be our actual virtual machines that will run containers for us. 
  • They're a lot more straightforward than the master.




Component's of Kubernetes node  

  • Kubelet:
    • It is an agent for Kubernetes.
    • It communicates with the control play and takes instructions such as deploying containers when it's told to.
  • Kube-proxy:
    • It is responsible for managing network connections in and out of the node.
  • Actual Container Runtime:
    • Just like when we run our first container in cloud shell the noble run docker as a container runtime to allow it to run containers.



How to build a Kubernetes cluster?

  • The hard way.
    • You'll need provision of virtual machines for you master and your nodes.
    • You'll need to install the Kubernetes software create a network overlay.
    • Set up certificates so that all of the components can talk to each other secularly.
  • The easy way.
    • Use GKE.
    • GKE provisions and manages the underlying cloud resources automatically.


GKE is a fully managed service

  • It will create masters and nodes for you to your specification using a container-optimized operating system.
  • You design your cluster within GKE without having to build or maintain individual masters or nodes.
  • It comes with built-in automatic upgrading, automatic self-repair.
  • It has many options for fine grain resource control and cluster scaling.
  • Its integrated with all of the other products and services Google cloud platform.
  • You don't even touch the master control plane.
  • It is completely managed for you.
  • It's made of compute engine VMs just like your nodes, but they won't even show up in your project.
  • Google's own CRET are looking after them for you.
  • Abstracting away the control plane takes away a lot of the operation overhead.


How do we operate and interact with GKE

  • Google Cloud Console.
    • Kubernetes functionality is exposed to us to the simple UI of the cloud console.
  • Command lines for Kubernetis
  • Kubectl for operating a running cluster
    • Kubectl allows us to interact with Kubernetes by defining the objects we want to deploy.
    • These objects are just abstractions of what we want to run and how we want to run it.
    • Kubectl takes our instructions and passes them to the API server.
  • Communicate with API Server
    • Perform their own function to carry out our commands.
  • Create and manage life-cycle of Kubernetes objects
    • Everything in Kubernetes is an object and every object has a state.



No comments:

Post a Comment