Let’s Talk: Containers and Kubernetes In Google Cloud Platform — Part 2

Published in

Nerd For Tech

5 min readApr 7, 2021

Referencing Part 1, we were able to understand the need for Kubernetes in the world of container orchestration. In this phase of the journey, we will talk a bit about nodes, kubectl, deployment and many other interesting Kubernetes concepts.

Nodes

There are many thoughts on exactly what nodes are about but in clarity. a Node is a worker machine in Kubernetes and may be either a virtual or a physical, depending on the cluster. Cluster admins create nodes and add them to Kubernetes. Furthermore GKE, it manages operations by deploying and registering to compute engine instances as nodes.

There are node pools that are a sub of the main nodes (they share workloads and other resources and it's more of a GKE feature than Kubernetes). Meanwhile, there are two types of cluster formats; Zonal and Regional. In context, the zonal cluster has a zone with a cluster, master and nodes for the application functionality — if the cluster or zone shuts down, the application might go down but for regional cluster covers such issues as the cluster is cut across three zones in the same region such that if any part of the cluster fails, the other keeps the job going. P.S: There is also a chance to do a private cluster and it has only access privately using GCP services or authorized networks but not open to the internet.

Kubernetes Object Management

All K8s objects are maintained by a unique name and Identifier. The objects could be defined in a YAML or JSON file but YAML is easier to read and understand as shown below:

apiVersion: apps/v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest

Best Practices: Learn to save the YAML file in the repository for version control from the cloud then of course you can also track and manage changes. Also, the objects must have unique names that could be string and it must be unique. There is also a unique ID for all the life of the cluster. Labels help identify objects and a subset of objects and could be sampled thus:

apiVersion: apps/v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
    env: dev
    stack: frontend
spec:
  replicas: 3
  selector:
    matchLabels
    app: nginx

Pods

Pods are the smallest, most basic deployable objects in Kubernetes — more like the atom of Kubernetes. A Pod represents a single instance of a running process in your cluster. One way to bring three Nginx instances together is to have them in separate pods with their corresponding YAML config. Now remember, due to its ephemeral state, the pods don’t stay forever, they have life cycles plus in a case where there are hundreds of instances, creating pods for each will be outrageous and that is why we are introducing controller objects to manage the state of the pods and check with its diff types like deployment, stateful set, daemonset and job.

Deployment and NameSpaces

There can be different nodes in the pods but should incase one shuts down, the deployment manager does a job of ensuring its recreation and comparing the current and desired state. There are also namespaces used to name pods, clusters, and nodes for identification and reference and they must always be unique. But you could use labels instead of namespaces but you should use based on factors. In applying namespaces, do them at the command line level as they make your YAML files more flexible in case of expansions and elasticity applications. Deployments manage replicaset for you and it does that replica set creation automatically.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploement
  labels:
    app: nginx
spec:
  replicas: 3
  template"  
   metadata:
     labels
       app: nginx
   spec:
     Containers:
     - name: nginx
       image: nginx:latest

Best Practice: You can apply a resource to a namespace when creating it, using a command-line namespace flag. Or, you can specify a namespace in the YAML file for the resource. Whenever possible, apply namespaces at the command line level. This practice makes your YAML files more flexible. For example, someday you might want to create two identical but completely independent instances of one of your deployments, each in its own namespace. This could be the case if you want to deploy into separate namespaces for testing before deploying into production. This is difficult if you have chosen to embed namespace names in your YAML files.

Service

The service represents a set of pods, structure, or function in the cluster. It could be used to connect the backend to the front end and maintain scalability and resource functions.

It works with a label selector for the pods’ communication and somehow sidelines the ephemeral nature of the pods IP. Also, endpoint resources is created as well then the virtual IP address used.

If you want storage shared between two pods/clusters within a container then it may be an issue because of the nature of the cluster. Kubernetes volume is a directory that is accessible to all the containers in a pod and its requirements can be decided using pod specifications and you must mount these volumes specifically on each container within a pod and you can set up volumes from external storage outside the pods for durable storage authenticity.

Best Practice: Volumes are ephemeral because if the pods are deleted, they could be deleted so you could configure the volume with network based storage outside of the pods.

There are other concepts and definitions to be addressed but it will be better in some topics to come because it will relate directly to the focus of that part. Now, remember, this article is not only for experts in the cloud space, even newbies could hop in and learn a lot and that is why I make everything clear both in layman and professional terms, so if you have any questions, shoot or you can also reach out to me on Twitter or find me on Github.

Thanks for reading ❤️

Please leave a comment if you have any thoughts about the topic — I am open to learning and knowledge explorations.

I can imagine how helpful this post has been, do leave a clap 👏 below a few times to show your support for the author!