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
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.
- 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.
- 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.
- 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
- 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.
- 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
- 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.
- 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.
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.