Ephemeral container is a special type of container that runs temporarily in an existing Pod to accomplish user-initiated actions such as troubleshooting. It is especially useful when kubectl exec is insufficient because a container has crashed or a container image doesn't include debugging utilities.
For instance, ephemeral containers help you execute a curl request from within pods that typically lack this utility.
Ephemeral containers are turned on by default in Kubernetes v1.23 and later
Wherever you can access pod resources in Devtron, you can launch an ephemeral container as shown below.
In the left sidebar, go to Applications.
Search and click your application from the list of Devtron Apps.
Go to the App Details tab.
Under the K8 Resources tab, select Pod inside Workloads.
Locate the pod you wish to debug. Hover and choose click Terminal.
Click Launch Ephemeral Container as shown below.
You get 2 tabs:
Basic - It provides the bare minimum configurations required to launch an ephemeral container.
It contains 3 mandatory fields:
Container name prefix - Type a prefix to give to your ephemeral container, for e.g., debug. Your container name would look like debug-jndvs.
Image - Choose an image to run from the dropdown. Ephemeral containers need an image to run and provide the capability to debug, such as curl. You can use a custom image too.
Target Container name - Since a pod can have one or more containers, choose a target container you wish to debug, from the dropdown.
Advanced - It is particularly useful for advanced users that wish to use labels or annotations since it provides additional key-value options. Refer Ephemeral Container Spec to view the supported options.
Click Launch Container.
Click here to know more.
(This is not a recommended method. This option is available only if you are an admin.)
You can launch an ephemeral container from Kubernetes CLI. For this, you need access to the cluster terminal on Devtron.
You can remove an ephemeral container using either App Details or Resource Browser (from the same screen you used to create the ephemeral container).
You cannot use App Details or Resource Browser to remove an ephemeral container created using Kubernetes CLI
If the deployment of your application is not successful, then debugging needs to be done to check the cause of the error.
This can be done through App Details section which you can access in the following way:-
Applications->AppName->App Details
Over here, you can see the status of the app as Healthy. If there are some errors with deployment then the status would not be in a Healthy state.
Events of the application are accessible from the bottom left corner.
Events section displays you the events that took place during the deployment of an app. These events are available until 15 minutes of deployment of the application.
Logs contain the logs of the Pods and Containers deployed which you can use for the process of debugging.
The Manifest shows the critical information such as Container-image, restartCount, state, phase, podIP, startTime etc. and status of the pods deployed.
You might run into a situation where you need to delete Pods. You may need to bounce or restart a pod.
Deleting a Pod is not an irksome task, it can simply be deleted by Clicking on Delete Pod.
Suppose you want to setup a new environment, you can delete a pod and thereafter a new pod will be created automatically depending upon the replica count.
You can view Application Objects in this section of App Details, such as:
You can monitor the application in the App Details section.
Metrics like CPU Usage, Memory Usage, Throughput and Latency can be viewed here.
| Key | Description |
|---|
| Key | Description |
|---|
| ReplicaSet(ensures how many replica of pod should be running), Status of Pod(status of the Pod) |
| Service(an abstraction which defines a logical set of Pods), Endpoints(names of the endpoints that implement a Service), Ingress(API object that manages external access to the services in a cluster) |
| ConfigMap( API object used to store non-confidential data in key-value pairs) |
| Rollout(new Pods will be scheduled on Nodes with available resources), ServiceMonitor(specifies how groups of services should be monitored) |
| Percentage of CPU's cycles used by the app. |
| Amount of memory used by app. |
| Performance of the app. |
| Delay caused while transmitting the data. |
Application metrics can be enabled to see your application's metrics.
Devtron provides certain metrics (CPU and Memory utilization) for each application by default i.e. you do not need to enable “Application metrics”. However, prometheus needs to be present in the cluster and the endpoint of the same should be updated in Global Configurations --> Clusters & Environments section.
There are certain advanced metrics (like Latency, Throughput, 4xx, 5xx, 2xx) which are only available when "Application metrics" is enabled from the Deployment Template. When you enable these advanced metrics, devtron attaches a envoy sidecar container to your main container which runs as a transparent proxy and passes each request through it to measure the advanced metrics.
Note: Since, all the requests are passed through envoy, any misconfiguration in envoy configs can bring your application down, so please test the configurations in a non-production environment extensively.
CPU usage is a utilization metric that shows the overall utilization of cpu by an application. It is available as both, aggregated or per pod.
Memory usage is a utilization metric that shows the overall utilization of memory by an application. It is available as both, aggregated or per pod.
This application metrics indicates the number of request processed by an application per minute.
This metrics indicates the application’s response to client’s request with a specific status code i.e 1xx(Communicate transfer protocol-level information), 2xx(Client’s request was accepted successfully), 3xx(Client must take some additional action to complete their request), 4xx(Client side error) or 5xx(Server side error).
Latency metrics shows the latency for an application. Latency measures the delay between an action and a response.
99.9th percentile latency: The maximum latency, in seconds, for the fastest 99.9% of requests.
99th percentile latency: The maximum latency, in seconds, for the fastest 99% of requests.
95th percentile latency: The maximum latency, in seconds, for the fastest 95% of requests.
Note: We also support custom percentile input inside the dropdown .A latency measurement based on a single request is not meaningful.
The users can access the on the App Details page.
Select Applications from the left navigation pane.
After selecting a configured application, select the App Details tab.
Note: If you enable
App admins can editon theExternal Linkspage, then only non-super admin users can view the selected links on theApp-Detailspage.
As shown in the screenshot, the external links appear on the App-Details level:
You can hover around an external link (e.g. Grafana) to view the description.
On the App Configuration page, select External Links from the navigation pane. You can see the configured external links which can be searched, edited or deleted.
You can also Add Link to add a new external link.
You can view the Ingress Host URL and the Load Balancer URL on the URLs section on the App Details. You can also copy the Ingress Host URL from the URLs instead of searching in the Manifest.
Select Applications from the left navigation pane.
After selecting your configured application, select the App Details.
Click URLs.
You can view or copy the URL of the Ingress Host.
Note:
The Ingress Host URL will point to the load balancer of your application.
You can also view the Service name with the load balancer detail.
The link opens in a new tab with the context you specified as env variables in the section.
