An Application is composed of one or more Components, where each Component maps to a construct in the Kubernetes Workloads API. In most cases an Application contains Kubernetes controllers like Deployments and StatefulSets, exposed as Services. The number of components will depend on your application architecture. For example some 3-tier applications may have a few components, or even a single component, where as Microservices style applications may have hundreds of services.
Applications are defined and stored in the Catalog. Once defined, an Application can be run in one or more Environments.
Changes made to an Application in the Catalog, can be propagated to Application instances running in Environments, based on the Environment’s Update Policy.
Here are some of the common constructs you can use to build Kubernetes applications with Nirmata:
Deployments (stateless components)
You can use Deployment for stateless services in your application. As part of your Deployment you can define a Pod template with one or more containers. For each container, you can add settings such as image information, run command, health checks, environment variables, volume mounts, container ports etc.
To enable communication with other components in your application, or with external clients, you can expose one or more ports of your containers by defining a Service.
StatefulSets (stateful components)
Some application components require stable identities e.g. distributed software tools may require that cluster members retain the same names and addresses within the cluster. Other software may manage large data sets, requiring reusing the same volume. StatefulSets address solve of these challenges, and provide additional controls over upgrades and restarts suitable for stateful services.
As with a Deployment, StatefulSets also contain a Pod template and can be referenced by a Service.
An Ingress manages external access to the services in a cluster, typically HTTP. Ingress can provide load balancing, SSL termination and name-based virtual hosting.
Prior to creating an Ingress for your application, you need to ensure that an Ingress Controller is available in your Kubernetes cluster.
Tip: To keep you Catalog Application portable, you should keep the ‘host’ field in the Ingress Rule empty or just provide a default value which should be customized once your application has been deployed in an environment. This will ensure that the host name is unique for your application.
Persistent Volume Claims
A PersistentVolumeClaim (PVC) is a request for storage for a pod. PVCs are used to create Persistent Volumes (PV) for your pods). PVCs can request specific size and access modes for storage.
Tip: When creating a StatefulSet, you can create VolumeClaimTemplates instead of using PVCs. This will allow you to scale your StatefulSet.
ConfigMaps enable you to decouple configuration from your container image, ensuring that your containerized application is portable.
ConfigMaps can be made available to your pod as:
- Environment variables
A ConfigMap can be shared across multiple pod templates further simplifying your application configuration.
Secrets can be created to store sensitive information such as password, certificates etc. Putting sensitive information in secrets is relatively secure compared to including it in your container image and provides flexibility in how these secrets can be accessed.
Secrets can be made available to your pod as:
- Environment variables
A Secret can be shared across multiple pod templates further simplifying your application configuration.
If your cluster supports network policy, you can configure them as part of your application. A network policy specifies how groups of pods are allowed to communicate with each other and other network endpoints.
Network Policies use labels to select pods and define rules which specify what traffic is allowed to the selected pods. By default, all pods in a Namespace can communicate with each other.