Kubernetes Objects Required For A Typical Web Application: Part I

By Sudheer S

From an application developer and Kubernetes user’s point of view, you have to have a working knowledge of Kubernetes. The post outlines the most important Kubernetes objects required to deploy a typical web application. Let us assume that the web application uses the two-tier architecture. We also assume that the cluster is created and administered by an infrastructure or DevOps engineer and the necessary access is provided to the developer to deploy their web application onto the Kubernetes cluster. The Kubernetes operations are performed from the web application developer’s perspective.

Prerequisites

  • Be able to develop web applications and deploy them to VMs in the cloud.
  • Be able to containerize the application using tools like Docker or Podman.
  • Use a container registry such as Docker, AWS ECR, etc.
  • Run containers on production servers using tools such as Docker or Podman.

In smaller teams, developers are probably expected to orchestrate and manage Kubernetes clusters for their organizations. In larger organizations, the network and cluster design and implementation is performed by infrastructure engineers. In any case, the web application developer is expected to know some basic Kubernetes concepts. The article describes a list of basic Kubernetes objects an application developer must know to deploy their application on to a Kubernetes cluster.

Application Architecture

  • Tier 1: PostgreSQL database. It is assumed that the database is hosted externally. ie, the database server itself does not sit on the cluster.
  • Tier 2: MVC framework that processes the request and generates the response with HTML markup in the body. Also serves static assets such as CSS, JavaScript, images and fonts by reading the file system.

Kubernetes Objects For A Web Application

Kubernetes Objects

  • Namespace. A Namespace is a logical boundary in the Kubernetes cluster often used for grouping and governance. For simple tests and learning, you will be creating the objects in the default namespace.
  • Pod built using the application container image. A pod is the basic unit object in Kubernetes. A pod can contain more than one container. Everything revolves around pods in Kubernetes.
  • ConfigMap. In the traditional VM based infrastructure, the application would read its configuration from an INI file, or some other format of configuration. On Kubernetes, the application can read such configuration values from its environment variables. Usually, the ConfigMap is exposed to the application via environment variables. They can contain values such as file system paths, external service endpoints, URLs, etc.
  • Secret. Kubernetes Secrets are similar to ConfigMaps and are meant to store sensitive and confidential data. Secrets are also exposed as environment variables to pods. Typically, they contain secrets such as database connection strings, API keys, tokens, etc.
  • Service a Service provides a stable IP, DNS name and for your application pods. Service in Kubernetes can be thought of as a load balancer, as it often distributes network traffic across multiple Pods in a Deployment, providing a single access point for clients.
  • ReplicaSet is a controller object that ensures a specific number of pod replicas are running at any given time.
  • Deployment. A simple Pod definition is fine. But Deployment provides greater control by specifying replica sets. The Pod definition is embedded into the Deployment object. Kubnernetes Deployment Illustration
  • Service Account. In a cloud environment, you grant permissions to resources using IAM. Cloud platforms provide a way to connect service accounts to IAM roles. Your application pod can mount a service account and gain access to cloud resources.
  • Ingress. Ingress provides a means to expose the web application to external traffic typically via the cloud provider’s load balancer service.

You can create all these objects in your local Kubernetes cluster created by Minikube.

The Kubernetes documentation does a fantastic job of explaining the concepts to the reader.

Web developer trying to take control of the helm

Further Steps

  • Create Kubernetes manifests in YAML format for all the above objects.
  • Deploy the manifests via kubectl on your local Minikube cluster.
  • Create a generic Helm chart that produces the Kubernetes manifests. If you have more than one application using similar patterns, templating and Helm will go a long way in generating the manifests.
  • Use sops to encrypt secrets. In the Kubernetes manifest for Secret, use the sops decrypted file.
  • In the Git repository, encrypt the secrets using sops. Use the helm-secrets plugin to decrypt the secrets before generating the Kubernetes manifest YAML.

References

Resources