Creating an Application manifest
Creating an application involves the following two steps:
- Adding an application to the Catalog
- Creating a deployment
Adding an application to the catalog
To add an application to the catalog:
- Go to Catalog and click Add Application.
Enter the name for the application and Select the type of the application. Refer the below details to select the appropriate application type
Catalog : Existing Applications can be imported using this Application type. Drag-drop the YAML file in the provided space and click on Save
Git: Application hosted on git can be added to the catalog using this type. Refer GitOps for more detail
Helm: Application can be added to the Catalog using helm charts using this type. Select a Chart Repository (refer to Import a helm chart for more details)Choose the Application and the respective chart Version. Check the values.yaml file displayed in values dialogue box. If required modify the values.YAML and click on Save
Once you have created the application, you should see the application model as shown below.
Creating a Pod Controller
A typical application in Kubernetes uses one of the following pod controller types:
- Deployment: good for stateless applications, and applications where instances do not require a fixed network identity or fixed storage.
- Statefulset: good for stateful applications that require stable identities.
NOTE: You must have access to the image repository for the application for creating a deployment.
To create a deployment:
- Click Add a Workload and select a deployment type in Workload Type tab.
- Click Next select your image repository in Pick an Image Registry tab.
- Enter the details for the image repository and click Next.
- Enter the port details in Add Network Ports tab to assign a port to the container on which the application will listen.
- Click Finish.
To edit a deployment, click on your image repository and update the required components.
You can also edit a Kubernetes compliant YAML file by clicking on the three-dot at the top-right corner in Deployment panel and selecting Edit YAML.
The process is similar for creating a StatefulSet.
Exposing an application as a service
In Kubernetes, you can expose your application as a service and give access to other applications or users, once your application has been deployed. The access can be given from outside the cluster or from other pods within the cluster.
To expose your application as a service:
Click Expose Deployment as a Service in the Deployment panel. The Expose as a Service screen appears.
Enter the name for the service and select a service type in General tab.
- Select ClusterIP to expose the application within the cluster.
- Select NodePort to expose the application externally.
This will allow a service on a specific port available to all the ports that are a part of the cluster. You can access the service at
NOTE: The default value for service type is set as ClusterIP.
- Enter the details of the port that will be exposed in Ports tab.
- Click Finish.
You can see the services under Discovery & Routing tab as shown below.
Creating an Ingress
An Ingress is used to access your application from outside the Kubernetes cluster.
Prior to creating an Ingress for your application, ensure that an Ingress Controller is available in the Kubernetes cluster to fulfill the ingress. Note that Google Kubernetes Engine (GKE) deploys an ingress controller on the master. Review the beta limitations of this controller if using GKE.
Nirmata allows you to use the same application YAML to deploy applications multiple times to the same cluster within different namespaces. To do so, the Ingress rule must be configured differently for each application.
In support, Nirmata allows multiple ingresses per a cluster and specific ingress settings per an environment and/or application by allowing the Ingress class notation to be specified for each Ingress rule. Configuring an Ingress rule at the application level allows you to add an Ingress policy to an environment to apply environment specific Ingress settings.
Additionally, some aspects of the Ingress rule, such as the Host name (subdomain) can be customized at a later date by another team to enforce Ingress policies when needed.
An Ingress policy contains:
- Host domain suffix (e.g. apps.nirmata.io)
- TLS enable/disable NOTE: if TLS is enabled, the Ingress should be configured for TLS using the same Ingress Host name
- Ingress annotations (e.g. ingress class kubernetes.io/ingress.class)
- Subdomain reference - you must specify a config map property to use as the subdomain name (e.g. application-defaults→app name) NOTE: if subdomain reference is not specified, the application run name can be used to generate the Ingress Host name
How to Configure an Ingress Rule at the Application Level
Open the application by selecting Catalog from the sidebar menu and then open Application. Click on the application card.
Once inside the application, select Discover & Routing and choose the option to Add an Ingress.
Create a Name for the ingress and select a Default Backend Service. Then click Next.
The backend is a combination of service and port names . HTTP (and HTTPS) requests to the ingress matching the host and path of the rule are sent to the listed backend. In most cases, a default backend is configured in the ingress controller. The default backend in the ingress controller services any requests that do not match the path in the specified path.
An ingress without rules sends all traffic to a single backend.
To keep the application portable, leave the Host field empty or provide a default value to customize when the application is deployed in an environment. This ensures that the host name is unique to the application.
When a Host is not specified, the ingress rule applies to all inbound HTTP traffic through the IP specified IP address.
If a Host is specified, the ingress rule applies only to the specified host.
Next, add a path(s).
Each path must be associated with a backend
servicePort. Both the host and path must match the content of an incoming request before the load balancer will direct traffic to the referenced service.
Note that on most Kubernetes project maintained distributions, communication between the user to the apiserver and from the apiserver to the kubelets is protected by SSL/TLS. Secrets are protected when transmitted over these channels.
Ingress can be secured by specifying a secret that contains a TLS private key and certificate. Kubernetes Ingress only supports TLS port 443 and assumes TLS termination .
If TLS is enabled, both Host name and Secret name must be configured. The TLS secret must contain keys named
tls.key that contain the certificate and private key to use for TLS.
apiVersion: v1 data: tls.crt: base64 encoded cert tls.key: base64 encoded key kind: Secret metadata: name: testsecret-tls namespace: default type: kubernetes.io/tls
Referencing this secret in an Ingress tells the Ingress controller to secure the channel from the client to the load balancer using TLS. The TLS secret must come from a certificate that contains a CN, such as
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: tls-example-ingress spec: tls: - hosts: - sslexample.foo.com secretName: testsecret-tls rules: - host: sslexample.foo.com http: paths: - path: / backend: serviceName: service1 servicePort: 80
The Host name is generated using the same Ingress Policy settings in non-TLS utilizations:
- configMapKey + configMapSelector → domain
The Secret name is stored in the ConfigMap selected by configMapSelector. The name of the key is stored as a new attribute of the IngressPolicy called MapSercretKey.
To create a new Secret name:
- Check that TSLEnabled is set to true
- Apply configMapSelector to retrieve the ConfigMap containing the Secret name
- Use the value of configMapSecretKey as the key to retrieve the value of the Secret name in ConfigMap