Building A Robust Kubernetes Deployment Update Strategy

In the dynamic realm of software development, staying ahead of the game is paramount. As the demand for seamless, efficient deployment of applications grows, so does the need for a well-crafted Kubernetes deployment update strategy. As any seasoned developer knows, the world of Kubernetes is a complex one, where every decision can impact the success of your application. In this blog, we will delve into the intricacies of Kubernetes deployment update strategies, exploring the key elements that define success, and highlighting the importance of staying up to date with the latest Kubernetes basics.

Picture this: you've developed the perfect application, meticulously tested and optimized for peak performance. The last thing you want is for your hard work to go to waste due to a faulty deployment update strategy. That's where Kubernetes comes in – a powerful container orchestration platform that enables you to manage and scale your applications with ease. But navigating the vast landscape of Kubernetes deployment update strategies can be daunting, especially for those new to the world of containerization. 

We will break down the essential elements that make up a successful Kubernetes deployment update strategy, empowering you to make informed decisions and take full advantage of this transformative technology. Whether you're a seasoned developer looking to optimize your deployment processes or a curious novice eager to learn the Kubernetes basics, this blog is your gateway to mastering the art of Kubernetes deployment update strategies. So, grab your coffee, settle in, and let's embark on this exciting journey together.

‍

Primary Purpose of A Kubernetes Deployment Update Strategy

The primary purpose of a Kubernetes Deployment Update Strategy is to enable seamless and efficient management of containerized applications. In Kubernetes, where containers have become the de facto standard for application packaging and deployment, having a well-defined update strategy is crucial for ensuring the stability and reliability of your applications. 

From Rolling Updates to Blue/Green Deployments: The Power of Kubernetes Deployment Update Strategy

A Kubernetes Deployment Update Strategy offers a range of options to update your applications while minimizing downtime and service disruptions. One such strategy is the rolling update, which allows for the gradual replacement of old containers with new ones, ensuring a smooth transition without impacting the overall availability of your application. This strategy is especially useful when you need to update your application without interrupting ongoing user requests.

Another powerful option is the Blue/Green deployment strategy, where two identical environments, referred to as Blue and Green, are maintained. The Blue environment represents the currently running version of your application, while the Green environment hosts the updated version. By routing traffic to the Green environment and gradually redirecting it away from the Blue environment, you can seamlessly update your application while ensuring zero downtime. This strategy is particularly beneficial for applications that require stringent performance and availability guarantees.

Managing Fault Tolerance and Rollbacks: Ensuring Application Resilience

A robust Kubernetes Deployment Update Strategy also offers fault tolerance mechanisms to handle potential failures during the update process. With features like health checks and readiness probes, Kubernetes can monitor the status of your containers and automatically roll back to the previous version if any issues arise. This ensures that your application remains resilient and minimizes the impact of potential failures.

Fine-tuning Updates with Strategies and Policies: Ensuring Control and Flexibility

Kubernetes also provides various update strategies and policies to give you fine-grained control over the update process. Strategies like "Recreate" can be used to update all containers simultaneously, while policies like "MaxSurge" and "MaxUnavailable" allow you to specify the maximum number of new containers that can be created or the maximum number of old containers that can be unavailable during the update. With these options, you can tailor the update strategy to meet the specific needs of your application and infrastructure.

Aiming for Continuous Delivery: Going Beyond Simple Updates

While a Kubernetes Deployment Update Strategy is essential for managing updates, it is just one piece of the puzzle in achieving a comprehensive continuous delivery workflow. By integrating your update strategy with other DevOps practices like automated testing, version control, and release management, you can streamline the deployment pipeline and ensure a smooth transition from development to production.

In containerized applications, a well-defined Kubernetes Deployment Update Strategy is the key to unlocking the full potential of your applications. By leveraging the power of rolling updates, Blue/Green deployments, fault tolerance mechanisms, and fine-tuning options, you can ensure seamless updates, maintain application resilience, and achieve continuous delivery. So, embrace the power of the Kubernetes Deployment Update Strategy and take your containerized applications to new heights of reliability and efficiency.

Related Reading

• Kubernetes Deployment Environment Variables
• Kubernetes Deployment Template
• Kubernetes Backup Deployment
• What Is Deployment In Kubernetes
• Scale Down Deployment Kubernetes
• Kubernetes Deployment History
• Kubernetes Deployment Best Practices
• Deployment Apps

Complete Guide On Building A Kubernetes Deployment Update Strategy

Kubernetes is a powerful container orchestration platform that allows you to manage and scale containerized applications. When it comes to updating a Kubernetes deployment, a well-thought-out strategy is essential to ensure a smooth transition and minimize any potential downtime. We will explore different strategies and techniques available for controlling the "rolling update" of pods during a Kubernetes Deployment update.

Strategy 1: Rolling Update

The rolling update strategy is the default update strategy in Kubernetes and is also the most commonly used. It ensures that the new version of the application is gradually rolled out while the old version is gradually phased out. This strategy provides a smooth transition by maintaining the desired number of replicas during the update process.

To define a rolling update strategy in a deployment, you can use the following YAML configuration:

	

	yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-app
  spec:  
   replicas: 3  
   strategy:    
    type: RollingUpdate    
    rollingUpdate:      
     maxUnavailable: 1      
     maxSurge: 1  
   template:    
  ...
	

‍

The `maxUnavailable` field specifies the maximum number of pods that can be unavailable during the update. The `maxSurge` field specifies the maximum number of pods that can be created above the desired number of replicas.

Strategy 2: Blue-Green Deployment

A blue-green deployment strategy involves running two identical environments, one serving as the active production environment (blue) and the other as the new version being deployed (green). This strategy allows for a seamless switch from the old version to the new version by routing traffic to the green environment once it is ready. To implement a blue-green deployment strategy in Kubernetes, you can use different techniques such as:

Using Service selectors

Create two services with different selectors, one pointing to the blue environment and the other to the green environment. Update the selectors to switch traffic from blue to green.

Using Ingress controllers

Configure the Ingress controller to route traffic to different services based on specific rules. Update the rules to switch traffic to the green environment.

Strategy 3: Canary Deployment

A canary deployment strategy involves gradually rolling out the new version of an application to a subset of users or traffic. This strategy allows for early testing and monitoring of the new version's performance before rolling it out to the entire user base. To implement a canary deployment strategy in Kubernetes, you can use techniques such as:

Using labels and selectors

Assign specific labels to pods running the new version and use selectors in services or ingress controllers to route a portion of traffic to those pods.

Using traffic splitting and routing

Utilize tools like Istio or Linkerd to split and route traffic based on specific rules. Gradually increase the percentage of traffic routed to the new version.

Strategy 4: Zero-Downtime Deployment

A zero-downtime deployment strategy aims to minimize or eliminate any interruption or downtime during the deployment process. It ensures that the application remains available to users throughout the update process.To achieve zero-downtime deployment in Kubernetes, you can employ techniques such as:

Using readiness and liveness probes

Configure readiness and liveness probes in your application's pods to ensure that only healthy pods receive traffic. This helps prevent any issues from being propagated to users during the update.

Using rolling updates with proper health checks

Configure rolling updates with suitable health checks, such as HTTP requests or TCP connections, to verify the readiness of the new pods before scaling down the old ones.

Building a robust and effective Kubernetes deployment update strategy is crucial for maintaining the availability and stability of your applications. By leveraging strategies like rolling updates, blue-green deployments, canary deployments, and zero-downtime deployments, you can ensure a smooth and controlled transition to new versions while minimizing any potential impact on your users.

Related Reading

• Kubernetes Deployment Logs
• Kubernetes Delete Deployment
• Kubernetes Deployment Strategy Types
• Kubernetes Blue Green Deployment
• Kubernetes Restart Deployment
• Kubernetes Update Deployment
• Kubernetes Canary Deployment
• Kubernetes Deployment Vs Pod
• Kubernetes Daemonset Vs Deployment
• Kubernetes Continuous Deployment
• Kubernetes Deployment Types
• Kubernetes Cheat Sheet
• Kubernetes Update Deployment With New Image
• Kubernetes Restart All Pods In Deployment
• Kubernetes Deployment Tools

‍

Defining The Desired State of A Kubernetes Deployment

In the world of Kubernetes deployment update strategies, defining the desired state is a crucial step in the process. The desired state represents the ideal configuration and characteristics that we want our deployment to have. By specifying the desired state, we are essentially providing the system with a blueprint of how we want our application to be deployed and managed.

One way to define the desired state of a Kubernetes Deployment is by creating a YAML file, which contains a set of instructions that describe the desired configuration of the deployment. This YAML file typically includes information such as the application name, the number of replicas, the image to be used, resource limits, and any other relevant configuration parameters.

Let's take a closer look at an example YAML file that defines the desired state of a Kubernetes Deployment:

	

	yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-app
  spec:  
   replicas: 3  
   selector:    
    matchLabels:      
     app: my-app  
   template:   
    metadata:      
     labels:        
      app: my-app    
    spec:      
     containers:      
     - name: my-app        
      image: my-app:latest        
      ports:         
      - containerPort: 8080

	

‍

In the above example, we are defining a deployment named "my-app" with a desired state of three replicas. The selector ensures that the pods created by this deployment will have the label "app: my-app". The template section defines the pod template that will be used for creating each replica. The container section specifies the container name, the image to be used, and the port on which the container will listen.

The Importance of the Desired State in the Update Process

The desired state plays a crucial role in the update process of a Kubernetes Deployment. When we want to make changes or updates to our application, Kubernetes relies on the desired state to determine how to bring the deployment from the current state to the desired state.

Kubernetes Update Mechanism

During an update, Kubernetes compares the current state of the deployment with the desired state defined in the YAML file. It then determines the necessary actions to be taken to update the deployment according to the desired state. These actions may include scaling up or down the number of replicas, rolling out new versions of the application, or modifying configuration parameters.

Clear Goals, Smooth Updates

By defining the desired state, we provide Kubernetes with a clear goal to work towards during the update process. This allows Kubernetes to orchestrate the necessary actions to achieve the desired state, ensuring a smooth and controlled deployment update.

Desired State as a Reference

The desired state also helps to ensure the consistency and reliability of our application. By specifying the desired configuration and characteristics, we can avoid discrepancies and inconsistencies that may arise due to manual interventions or misconfigurations. The desired state acts as a reference point that Kubernetes can use to verify the correctness of the deployment and make any necessary adjustments.

Defining the desired state of a Kubernetes Deployment is a crucial step in the update process. By specifying the desired configuration and characteristics, we provide Kubernetes with a clear goal to work towards and ensure the consistency and reliability of our application. Through a YAML file, we can define the desired state and allow Kubernetes to orchestrate the necessary actions to bring the deployment to the desired state. So, let's harness the power of the desired state and unleash the full potential of our Kubernetes deployments.

MaxUnavailable

One of the key aspects of managing and updating applications in Kubernetes is ensuring high availability and minimal disruption to users. When a deployment update is initiated, Kubernetes ensures that the desired state of the deployment is achieved by gradually terminating old pods and creating new ones. The "MaxUnavailable" parameter plays a crucial role in determining the availability of pods during this process.

Fine-Tuning Deployments

The "MaxUnavailable" parameter specifies the maximum number or percentage of pods that can be unavailable during the deployment update. It allows operators to control the rate at which old pods are terminated and new ones are created. By setting a value for "MaxUnavailable," operators can ensure that a certain number or percentage of pods are always available and serving traffic while the update is in progress.

Strategic Pod Termination

For example, let's say we have a deployment with 10 replicas and we set "MaxUnavailable" to 2. During the update, Kubernetes will terminate a maximum of 2 pods at a time, ensuring that at least 8 pods remain available at any given time. This helps maintain the overall availability of the application and prevents a sudden drop in service.

To better understand how the "MaxUnavailable" parameter works, let's take a look at some code snippets. In the following example, we have a deployment with 3 replicas and we set "MaxUnavailable" to 1:

	

	yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-deployment
  spec:  
   replicas: 3  
   strategy:    
    type: RollingUpdate    
    rollingUpdate:      
     maxUnavailable: 1  
   template:    
    ...

	

‍

Kubernetes will follow a rolling update strategy and terminate one pod at a time. It will wait for the new pod to become ready before proceeding to the next one. This ensures that there are always at least 2 out of 3 pods available during the update.

Strategic Configuration

Why is the "MaxUnavailable" parameter significant in Kubernetes deployment updates? Well, it allows operators to strike a balance between availability and speed of the update process. By carefully configuring this parameter, operators can ensure that the update progresses smoothly while still maintaining a certain level of availability.

Fine-Tuning Updates

If the "MaxUnavailable" value is set too low, it may slow down the update process, as Kubernetes will be cautious not to exceed the maximum number of unavailable pods. On the other hand, if the value is set too high, it could lead to a temporary degradation in availability as more pods are taken down simultaneously.

Availability vs. Speed

Therefore, finding the right balance is crucial. By setting an appropriate value for "MaxUnavailable," operators can update their applications with minimal downtime and ensure a seamless experience for their users.

When it comes to Kubernetes deployment updates, the "MaxUnavailable" parameter plays a vital role in managing availability. By defining the maximum number or percentage of pods that can be unavailable at any given time, operators can control the update process and strike a balance between availability and speed. This allows for smooth updates and ensures a seamless experience for users.

MaxSurge

One of the key aspects of managing applications in a Kubernetes cluster is updating their deployments. Kubernetes offers various strategies to ensure seamless updates, and one such strategy involves the use of the "MaxSurge" parameter. Understanding the role of "MaxSurge" is crucial for effectively managing the scaling behavior of your deployments during updates. Let's delve into this topic and explore its significance in Kubernetes deployment update strategies.

Exploring "MaxSurge"

The "MaxSurge" parameter is a configuration option available in Kubernetes deployments. It specifies the maximum number of additional pods that can be created during an update. When a deployment is updated, Kubernetes follows a rolling update process, which gradually replaces the old pods with new ones. The "MaxSurge" parameter comes into play during this process by determining the upper limit for the number of additional pods that can be created.

Understanding Scaling Behavior

To comprehend how "MaxSurge" influences scaling behavior, we must first grasp the concept of scaling itself. In Kubernetes, scaling refers to adjusting the number of pods running for a particular deployment to meet the application's demand. It ensures optimal resource utilization and enables applications to handle varying workloads effectively.

During a deployment update, Kubernetes scales the number of pods based on the desired replicas specified in the deployment manifest. By manipulating the "MaxSurge" parameter, you can control the scaling behavior and make it more flexible or conservative, depending on your application's requirements.

Implications and Code Examples

Let's explore a couple of scenarios to understand how the "MaxSurge" parameter affects scaling behavior.

Scenario 1: Conservative Scaling

Suppose you have a deployment with three replicas and set the "MaxSurge" parameter to 0 during an update. Kubernetes will replace one old pod with a new one at a time, ensuring that the total number of pods never exceeds the desired replicas count. This conservative approach minimizes the risk of resource contention or performance degradation during updates.

Example:

	

	apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-app
  spec:  
   replicas: 3 
   strategy:    
    type: RollingUpdate    
    rollingUpdate:      
     maxSurge: 0      
     maxUnavailable: 1  
   template:    
    ...

	

‍

Scenario 2: Flexible Scaling

Now, imagine you set the "MaxSurge" parameter to 2 during an update. Kubernetes will create up to two additional pods beyond the desired replica count while replacing the old pods. This allows for a more flexible scaling behavior, which can be beneficial when your application can handle a temporarily higher number of pods without any adverse effects.

‍
Example:

	

	apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-app
  spec:  
   replicas: 3  
   strategy:    
    type: RollingUpdate    
    rollingUpdate:      
     maxSurge: 2      
     maxUnavailable: 1  
   template:    
    ...

	

‍

Understanding the role of the "MaxSurge" parameter in Kubernetes deployment updates is crucial for effectively managing scaling behavior. By adjusting this parameter, you can control the number of additional pods created during updates, striking a balance between flexibility and resource utilization. Whether you opt for a conservative or flexible scaling approach depends on your application's specific requirements and the tolerance for temporary resource contention. By leveraging the power of "MaxSurge," you can ensure seamless updates and optimal performance for your Kubernetes deployments.

Revision History

In the world of containerization and microservices, managing updates and rollbacks can be a challenging task. Kubernetes, an open-source container orchestration platform, offers a powerful deployment update strategy that includes revision history. This feature plays a crucial role in supporting rollbacks and version management, ensuring the smooth and reliable operation of applications. Let's delve into the purpose of revision history and how it empowers Kubernetes deployments.

What is Revision History in Kubernetes Deployment?

Revision history in Kubernetes deployment refers to a record of all the changes made to a deployment over time. It captures every modification made to the deployment's desired state, including updates to the container image, environment variables, and resource limits. This history is maintained by the Kubernetes controller as a list of revisions, each representing a unique version of the deployment.

Supporting Rollbacks

One of the primary purposes of revision history is to support rollbacks in Kubernetes deployments. Rollbacks are necessary when an update introduces bugs or unforeseen issues, causing the application to malfunction. With revision history, operators can easily revert to a previous version of the deployment, restoring the application's functionality to a known working state.

To perform a rollback, operators can use the `kubectl rollout undo` command, specifying the deployment and target revision. Kubernetes will automatically rollback the deployment to the specified revision, ensuring the application is back to a stable state. This rollback process is seamless and minimizes downtime, allowing operators to quickly respond to issues and ensure a smooth user experience.

Version Management

Revision history also plays a critical role in version management for Kubernetes deployments. By maintaining a record of all changes, operators can easily track and manage different versions of an application. This is particularly useful when testing new features or conducting A/B testing, where multiple versions of the application need to coexist.

Metadata Magic

Operators can list all revisions of a deployment using the `kubectl rollout history` command, providing a comprehensive overview of different versions. This allows them to compare the performance and behavior of each version, making informed decisions regarding updates and rollbacks.

Documentation Excellence

Operators can annotate revisions with relevant metadata, such as release notes or bug fix descriptions. This helps in documenting the deployment's evolution and provides valuable insights for future reference.

Example Code: Revision History in Action

Let's take a look at an example deployment yaml file showcasing the revision history feature in Kubernetes:

	

	apiVersion: apps/v1
  kind: Deployment
  metadata:  
   name: my-app
  spec:  
   replicas: 3  
   selector:    
    matchLabels:      
     app: my-app  
     template:    
     metadata:      
     labels:        
      app: my-app    
    spec:      
     containers:      
     - name: my-app-container        
      image: my-app:latest        
      ports:        
      - containerPort: 8080

	

‍

In this example, we have a simple deployment named "my-app" with three replicas. The deployment creates pods running the container image "my-app:latest" and exposes port 8080.

When an update is made to this deployment, Kubernetes creates a new revision in its revision history, capturing the changes made. Operators can then use this revision history to track and manage different versions of the deployment, performing rollbacks if needed.

In the world of Kubernetes, revision history is a valuable tool for managing updates and rollbacks in deployments. Maintaining a detailed record of changes enables operators to easily revert to previous versions, ensuring the stability and reliability of applications. Version management becomes more streamlined as operators can track different versions and annotate revisions with relevant information. With revision history, Kubernetes empowers operators to confidently deploy and manage applications in a dynamic and ever-changing environment.

Best Practices for Managing A Kubernetes Deployment Update Strategy

In the world of container orchestration, Kubernetes has emerged as the leading platform for managing and scaling applications. With its robust deployment capabilities, Kubernetes allows teams to easily update their applications while ensuring reliability and consistency. Designing and managing a Kubernetes Deployment Update Strategy requires careful planning and consideration. We will explore the best practices and considerations that can help you achieve a reliable and consistent update strategy for your Kubernetes deployments.

1. Rolling Updates: Ensuring High Availability

One of the key considerations when updating a Kubernetes deployment is maintaining the high availability of the application. Kubernetes provides a rolling update strategy, which ensures that the application remains available during the update process. This strategy ensures that the new version of the application is gradually rolled out, while the old version is gracefully phased out. To implement a rolling update, you can specify the update strategy as "RollingUpdate" in the deployment configuration file:

	

	yaml
  ...
  strategy:  
   type: RollingUpdate 
    rollingUpdate:    
     maxUnavailable: 25%   
     maxSurge: 25%
  ...

	

‍

The `maxUnavailable` and `maxSurge` parameters control the number or percentage of pods that can be unavailable or surplus during the update process. By carefully tuning these parameters, you can ensure a smooth update process while maintaining high availability.

2. Canary Deployments: Reducing Risk with Gradual Rollouts

Another best practice for updating Kubernetes deployments is to use canary deployments. Canary deployments involve rolling out the new version of the application to a small subset of users or nodes, allowing you to test its performance and stability before updating the entire deployment. This approach helps reduce the risk of introducing bugs or performance issues to the production environment.

To implement a canary deployment, you can use Kubernetes' advanced features such as traffic splitting and ingress controllers. By directing a portion of the traffic to the new version of the application, you can closely monitor its behavior and gather feedback from real users. Once you are confident in the new version's performance, you can gradually increase the traffic to the new version and complete the update process.

3. Automated Testing: Ensuring Quality and Stability

A crucial aspect of a reliable update strategy is automated testing. By automating testing processes, you can ensure that the new version of the application is thoroughly tested before being deployed to production. Kubernetes provides various tools and frameworks for automated testing, such as integration tests, unit tests, and end-to-end tests.

You can integrate these testing frameworks into your Continuous Integration and Continuous Deployment (CI/CD) pipeline to automate the testing process. By running these tests in a pre-production environment, you can identify and fix any issues or regressions before updating the production deployment. This ensures that the new version maintains the desired level of quality and stability.

4. Rollback Strategy: Reverting to a Previous Version

Despite careful planning and testing, updates can sometimes introduce unexpected issues or regressions. Therefore, it is crucial to have a rollback strategy in place to quickly revert to a previous version in case of emergencies. Kubernetes provides a simple rollback mechanism that allows you to easily roll back to a previous version of the deployment:

	

	bash
  kubectl rollout undo deployment/

	

‍

By monitoring the health and performance of the updated deployment, you can quickly detect any issues and trigger a rollback if necessary. It is essential to carefully plan and document the rollback process to minimize the impact on users and ensure a smooth transition.

Designing and managing a Kubernetes Deployment Update Strategy requires careful planning and consideration. By following best practices such as rolling updates, canary deployments, automated testing, and having a robust rollback strategy, you can ensure the reliability and consistency of your application updates. These practices help minimize downtime, reduce risk, and maintain high availability, ultimately enabling you to deliver a seamless user experience.

Become a 1% Developer Team With Zeet

Are you a startup or small business looking to maximize the potential of your cloud infrastructure and streamline your Kubernetes deployment update strategy? Look no further, because Zeet is here to help you get the most out of your investments and empower your engineering team to become strong individual contributors.

Crafting a Kubernetes Deployment Update Plan for Your Needs

At Zeet, we understand the unique challenges faced by startups and small businesses. With limited resources and a need to scale quickly, it's crucial to have a reliable and efficient system in place for deploying and updating your applications on Kubernetes. That's where our expertise comes in.

Empowering Engineering Teams

Our team will work closely with you to design a Kubernetes deployment update strategy that is tailored to your specific needs. We'll take into account factors such as your size, growth projections, and technical requirements to create a plan that ensures seamless updates without compromising the stability of your applications.

Zeet's Commitment to Seamless Application Updates

One of the key advantages of using Zeet is our focus on empowering your engineering team. We believe that every member of your team has the potential to contribute to your success and that a robust Kubernetes deployment update strategy plays a crucial role in enabling them to do so. Our platform provides the tools and resources needed for your engineers to take ownership of their deployments, making them more efficient and productive.

How Zeet Enhances Engineering Productivity in Updates

With Zeet, you can expect a high level of reliability and availability for your applications. Our platform is built to handle the demands of modern cloud environments, ensuring that your deployments are secure and performant. We also offer comprehensive monitoring and troubleshooting capabilities, giving you the peace of mind that your applications are running smoothly.

From Startups to Mid-Market

Whether you're a startup or a mid-market company, our goal at Zeet is to help you achieve your business objectives by maximizing the potential of your cloud and Kubernetes investments. We strive to provide you with the expertise and support needed to navigate the complexities of modern infrastructure and empower your engineering team to excel.

Don't settle for a suboptimal Kubernetes deployment update strategy. Let Zeet take your cloud infrastructure to the next level and help your team become strong individual contributors. Contact us today to learn more about how we can revolutionize your deployment process.

Related Reading

• Kubernetes Rollback Deployment
• Kubernetes Service Vs Deployment
• Deployment As A Service
• Kubernetes Deployment Env
• Deploy Kubernetes Dashboard