Comment on page
Rollout Deployment
The
Rollout Deployment chart deploys an advanced version of deployment that supports Blue/Green and Canary deployments. For functioning, it requires a rollout controller to run inside the cluster.You can define application behavior by providing information in the following sections:
Key | Descriptions |
|---|---|
Chart Version | Select the Chart Version using which you want to deploy the application. |
Devtron uses helm charts for the deployments. And we are having multiple chart versions based on features it is supporting with every chart version.
One can see multiple chart version options available in the drop-down. you can select any chart version as per your requirements. By default, the latest version of the helm chart is selected in the chart version option.
Every chart version has its own YAML file. Helm charts are used to provide specifications for your application. To make it easy to use, we have created templates for the YAML file and have added some variables inside the YAML. You can provide or change the values of these variables as per your requirement.
If you want to see Application Metrics (as an example, Status codes 2xx, 3xx, 5xx; throughput, and latency etc.) for your application, then you need to select the latest chart version.
Note: Application Metrics are not supported for the Chart version older than 3.7 version.
Some of the use-cases which are defined on the Deployment Template (YAML file) may not be applicable to configure for your application. In such cases, you can do the basic deployment configuration for your application on the Basic GUI section instead of configuring the YAML file.
The following fields are provided on the Basic GUI section:
Fields | Description |
|---|---|
Port | The internal HTTP port. |
HTTP Request Routes | Enable the HTTP Request Routes to define Host and Path. By default, it is in disabled state.
You can define multiple paths as required by clicking Add path. |
CPU | The CPU resource as per the application. |
RAM | The RAM resource as per the application. |
Environment Variables (Key/Value) | Define key/value by clicking Add variable.
You can define multiple env variables by clicking Add variable. |
Click Save Changes.
If you want to do additional configurations, then click Advanced (YAML) for modifications.
Note: If you change any values in the
Basic GUI, then the corresponding values will be changed in YAML file also.This defines the ports on which application services will be exposed to other services.
ContainerPort:
- envoyPort: 8799
envoyTimeout: 15s
idleTimeout:
name: app
port: 8080
servicePort: 80
supportStreaming: true
useHTTP2: true
Key | Description |
|---|---|
envoyPort | envoy port for the container. |
envoyTimeout | envoy Timeout for the container,envoy supports a wide range of timeouts that may need to be configured depending on the deployment.By default the envoytimeout is 15s. |
idleTimeout | the duration of time that a connection is idle before the connection is terminated. |
name | name of the port. |
port | port for the container. |
servicePort | port of the corresponding kubernetes service. |
supportStreaming | Used for high performance protocols like grpc where timeout needs to be disabled. |
useHTTP2 | Envoy container can accept HTTP2 requests. |
EnvVariables: []
EnvVariables provide run-time information to containers and allow to customize how the application works and the behavior of the applications on the system.Here we can pass the list of env variables , every record is an object which contain the
name of variable along with value.To set environment variables for the containers that run in the Pod.
IMP Docker image should have env variables, whatever we want to set.EnvVariables:
- name: HOSTNAME
value: www.xyz.com
- name: DB_NAME
value: mydb
- name: USER_NAME
value: xyz
But
ConfigMap and Secret are the prefered way to inject env variables. You can create this in App Configuration Section.It is a centralized storage, specific to k8s namespace where key-value pairs are stored in plain text.
It is a centralized storage, specific to k8s namespace where we can store the key-value pairs in plain text as well as in encrypted(
Base64) form.
IMP All key-values of Secret and CofigMap will reflect to your application.If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
LivenessProbe:
Path: ""
port: 8080
initialDelaySeconds: 20
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
failureThreshold: 3
command:
- python
- /etc/app/healthcheck.py
httpHeaders:
- name: Custom-Header
value: abc
scheme: ""
tcp: true
Key | Description |
|---|---|
Path | It define the path where the liveness needs to be checked. |
initialDelaySeconds | It defines the time to wait before a given container is checked for liveliness. |
periodSeconds | It defines how often (in seconds) to perform the liveness probe. |
successThreshold | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
timeoutSeconds | The maximum time (in seconds) for the probe to complete. |
failureThreshold | The number of consecutive failures required to consider the probe as failed. |
command | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
httpHeaders | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
scheme | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
tcp | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
MaxUnavailable: 0
The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
MaxSurge: 1
The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count. The default value of "MaxSurge: " is 25%.
MinReadySeconds: 60
This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
ReadinessProbe:
Path: ""
port: 8080
initialDelaySeconds: 20
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
failureThreshold: 3
command:
- python
- /etc/app/healthcheck.py
httpHeaders:
- name: Custom-Header
value: abc
scheme: ""
tcp: true
Key | Description |
|---|---|
Path | It define the path where the readiness needs to be checked. |
initialDelaySeconds | It defines the time to wait before a given container is checked for readiness. |
periodSeconds | It defines how often (in seconds) to perform the readiness probe. |
successThreshold | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
timeoutSeconds | The maximum time (in seconds) for the probe to complete. |
failureThreshold | The number of consecutive failures required to consider the probe as failed. |
command | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
httpHeaders | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
scheme | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
tcp | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
Startup Probe in Kubernetes is a type of probe used to determine when a container within a pod is ready to start accepting traffic. It is specifically designed for applications that have a longer startup time.
StartupProbe:
Path: ""
port: 8080
initialDelaySeconds: 20
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
failureThreshold: 3
httpHeaders:
- name: Custom-Header
value: abc
command:
- python
- /etc/app/healthcheck.py
tcp: false
Key | Description |
|---|---|
Path | It define the path where the startup needs to be checked. |
initialDelaySeconds | It defines the time to wait before a given container is checked for startup. |
periodSeconds | It defines how often (in seconds) to perform the startup probe. |
successThreshold | The number of consecutive successful probe results required to mark the container as ready. |
timeoutSeconds | The maximum time (in seconds) for the probe to complete. |
failureThreshold | The number of consecutive failures required to consider the probe as failed. |
command | The mentioned command is executed to perform the startup probe. If the command returns a non-zero value, it's equivalent to a failed probe. |
httpHeaders | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
tcp | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
This is connected to HPA and controls scaling up and down in response to request load.
autoscaling:
enabled: false
MinReplicas: 1
MaxReplicas: 2
TargetCPUUtilizationPercentage: 90
TargetMemoryUtilizationPercentage: 80
extraMetrics: []
Key | Description |
|---|---|
enabled | Set true to enable autoscaling else set false. |
MinReplicas | Minimum number of replicas allowed for scaling. |
MaxReplicas | Maximum number of replicas allowed for scaling. |
TargetCPUUtilizationPercentage | The target CPU utilization that is expected for a container. |
TargetMemoryUtilizationPercentage | The target memory utilization that is expected for a container. |
extraMetrics | Used to give external metrics for autoscaling. |
fullnameOverride: app-name
fullnameOverride replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.image:
pullPolicy: IfNotPresent
Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
serviceAccount:
create: false
name: ""
annotations: {}
Key | Description |
|---|---|
enabled | Determines whether to create a ServiceAccount for pods or not. If set to true, a ServiceAccount will be created. |
name | Specifies the name of the ServiceAccount to use. |
annotations | Specify annotations for the ServiceAccount. |
imagePullSecrets contains the docker credentials that are used for accessing a registry.imagePullSecrets:
- regcred
regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ .
the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
hostAliases:
- ip: "192.168.1.10"
hostnames:
- "hostname1.example.com"
- "hostname2.example.com"
- ip: "192.168.1.11"
hostnames:
- "hostname3.example.com"
This allows public access to the url. Please ensure you are using the right nginx annotation for nginx class. The default value is
nginx.ingress:
enabled: false
# For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
className: nginx
annotations: {}
hosts:
- host: example1.com
pathType: "ImplementationSpecific"
paths:
- /example
- host: example2.com
pathType: "ImplementationSpecific"
paths:
- /example2
- /example2/healthz
tls: []
Legacy deployment-template ingress format
ingress:
enabled: false
# For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
ingressClassName: nginx-internal
annotations: {}
path: ""
host: ""
tls: []
Key | Description |
|---|---|
enabled | Enable or disable ingress |
annotations | To configure some options depending on the Ingress controller |
host | Host name |
pathType | Path in an Ingress is required to have a corresponding path type. Supported path types are ImplementationSpecific, Exact and Prefix. |
path | Path name |
tls | It contains security details |
This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
ingressInternal:
enabled: false
# For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
ingressClassName: nginx-internal
annotations: {}
hosts:
- host: example1.com
pathType: "ImplementationSpecific"
paths:
- /example
- host: example2.com
pathType: "ImplementationSpecific"
paths:
- /example2
- /example2/healthz
tls: []
Key | Description |
|---|---|
enabled | Enable or disable ingress |
annotations | To configure some options depending on the Ingress controller |
host | Host name |
pathType | Path in an Ingress is required to have a corresponding path type. Supported path types are ImplementationSpecific, Exact and Prefix. |
path | Path name |
pathType | Supported path types are ImplementationSpecific, Exact and Prefix. |
tls | It contains security details |
initContainers:
- reuseContainerImage: true
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumeMounts:
- mountPath: /etc/ls-oms
name: ls-oms-cm-vol
command:
- flyway
- -configFiles=/etc/ls-oms/flyway.conf
- migrate
- name: nginx
image: nginx:1.14.2
securityContext:
privileged: true
ports:
- containerPort: 80
command: ["/usr/local/bin/nginx"]
args: ["-g", "daemon off;"]
Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to
true.pauseForSecondsBeforeSwitchActive: 30
To wait for given period of time before switch active the container.
These define minimum and maximum RAM and CPU available to the application.
resources:
limits:
cpu: "1"
memory: "200Mi"
requests:
cpu: "0.10"
memory: "100Mi"
Resources are required to set CPU and memory usage.
Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
Requests are what the container is guaranteed to get.
This defines annotations and the type of service, optionally can define name also.
service:
type: ClusterIP
annotations: {}
Key | Description |
|---|---|
type | Select the type of service, default ClusterIP |
annotations | Annotations are widely used to attach metadata and configs in Kubernetes. |
name | Optional field to assign name to service |
loadBalancerSourceRanges | If service type is LoadBalancer, Provide a list of whitelisted IPs CIDR that will be allowed to use the Load Balancer. |
Note - If
loadBalancerSourceRanges is not set, Kubernetes allows traffic from 0.0.0.0/0 to the LoadBalancer / Node Security Group(s).volumes:
- name: log-volume
emptyDir: {}
- name: logpv
persistentVolumeClaim:
claimName: logpvc
It is required when some values need to be read from or written to an external disk.
volumeMounts:
- mountPath: /var/log/nginx/
name: log-volume
- mountPath: /mnt/logs
name: logpvc
subPath: employee
It is used to provide mounts to the volume.
Spec:
Affinity:
Key:
Values:
Spec is used to define the desire state of the given container.
Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
Taints are the opposite, they allow a node to repel a set of pods.
A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
args:
enabled: false
value: []
This is used to give arguments to command.
command:
enabled: false
value: []
workingDir: {}
It contains the commands to run inside the container.
Key | Description |
|---|---|
enabled | To enable or disable the command. |
value | It contains the commands. |
workingDir | It is used to specify the working directory where commands will be executed. |
Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to
true. containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
command: ["/usr/local/bin/nginx"]
args: ["-g", "daemon off;"]
- reuseContainerImage: true
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumeMounts:
- mountPath: /etc/ls-oms
name: ls-oms-cm-vol
command:
- flyway
- -configFiles=/etc/ls-oms/flyway.conf
- migrate
prometheus:
release: monitoring
It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
rawYaml:
- apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
type: ClusterIP
Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
GracePeriod: 30
Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the
GracePeriod.A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
server:
deployment:
image_tag: 1-95a53
image: ""
It is used for providing server configurations.
It gives the details for deployment.
Key | Description |
|---|---|
image_tag | It is the image tag |
image | It is the URL of the image |
servicemonitor:
enabled: true
path: /abc
scheme: 'http'
interval: 30s
scrapeTimeout: 20s
metricRelabelings:
- sourceLabels: [namespace]
regex: '(.*)'
replacement: myapp
targetLabel: target_namespace
It gives the set of targets to be monitored.
dbMigrationConfig:
enabled: false
It is used to configure database migration.
These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
istio:
enable: true
gateway:
enabled: true
labels:
app: my-gateway
annotations:
description: "Istio Gateway for external traffic"
host: "example.com"
tls:
enabled: true
secretName: my-tls-secret
virtualService:
enabled: true
labels:
app: my-service
annotations:
description: "Istio VirtualService for routing"
gateways:
- my-gateway
hosts:
- "example.com"
http:
- match:
- uri:
prefix: /v1
route:
- destination:
host: my-service-v1
subset: version-1
- match:
- uri:
prefix: /v2
route:
- destination:
host: my-service-v2
subset: version-2
destinationRule:
enabled: true
labels:
app: my-service
annotations:
description: "Istio DestinationRule for traffic policies"
subsets:
- name: version-1
labels:
version: "v1"
- name: version-2
labels:
version: "v2"
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
outlierDetection:
consecutiveErrors: 5
interval: 30s
baseEjectionTime: 60s
peerAuthentication:
enabled: true
labels:
app: my-service
annotations:
description: "Istio PeerAuthentication for mutual TLS"
selector:
matchLabels:
version: "v1"
mtls:
mode: STRICT
portLevelMtls:
8080:
mode: DISABLE
requestAuthentication:
enabled: true
labels:
app: my-service
annotations:
description: "Istio RequestAuthentication for JWT validation"
selector:
matchLabels:
version: "v1"
jwtRules:
- issuer: "issuer-1"
jwksUri: "https://issuer-1/.well-known/jwks.json"
authorizationPolicy:
enabled: true
labels:
app: my-service
annotations:
description: "Istio AuthorizationPolicy for access control"
action: ALLOW
provider:
name: jwt
kind: Authorization
rules:
- from:
- source:
requestPrincipals: ["*"]
to:
- operation:
methods: ["GET"]