Migrating Kubernetes applications between clusters and clouds is a complex and challenging task, particularly when it comes to ensuring consistency in Ingress configurations across different cloud providers. Ingress objects manage external access to services in a Kubernetes cluster, and each cloud provider has its own set of requirements and configuration options for Ingress.
This article provides an overview of the various Ingress configuration options available in popular cloud platforms, such as Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (AWS EKS), and Azure Kubernetes Service (AKS). Additionally, this article offers advice on how to simplify the migration of generic Free and Open Source Software (FOSS) Ingress solutions.
By the end of this article, readers will have a better understanding of the various Ingress configuration options available in different cloud platforms, as well as strategies for simplifying the migration of Ingress solutions between clouds.
Migrating Kubernetes applications with Kasten K10
Kasten K10 by Veeam provides a robust platform for managing Kubernetes applications across different cloud environments. With Kasten K10, you can easily migrate your Kubernetes applications from one cloud to another, without worrying about the complexities of Ingress configuration.
Kasten K10's export/import actions are designed for replicating Kubernetes applications between clouds of the same or different vendors. The solution also provides a transform mechanism that enables you to modify the necessary specification attributes of a migrated Kubernetes object before restoring it in the target cloud. This helps to mitigate configuration inconsistencies that may occur during the migration process.
In addition, Kasten K10 offers predefined transform examples that can be adapted easily to adjust Ingress configurations, according to the specific requirements of different cloud providers such as Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (AWS EKS), and Azure Kubernetes Service (AKS).
With Kasten K10's powerful features, you can streamline the replication of Kubernetes applications across clouds while ensuring that Ingress configurations are correctly adapted to the target cloud.
More information about migrating applications can be found here.
Adjustments required for migrating Kubernetes Ingress objects
When migrating Ingress objects between cloud providers such as GKE, AWS EKS, and AKS, several adjustments are necessary to ensure the objects function correctly on the target cluster:
The Ingress Controller must be configured, and the Ingress object must be relinked to it. As different clouds support different Ingress controllers, you must ensure that the target cluster has either the same Ingress controller or another controller that can function correctly with the migrated Ingress configuration. If you’re using a different controller, you should update the Ingress object specification accordingly to point to the new controller.
Updating the TLS certificate is necessary when the Ingress object uses TLS encryption to protect traffic. It's crucial to verify that the TLS certificate is available on the target cluster and update the Ingress object specification with the correct secret name that holds the required TLS certificate.
Vendor-specific Ingress annotations must be updated to reflect the unique features provided by each cloud provider. When migrating between different cloud vendors, you should remove vendor-specific annotations in the Ingress object specification from the source cluster, and apply new annotations specific to the target cloud provider.
If you make these adjustments, the migrated Ingress object will function correctly on the target cloud provider's cluster, providing secure and reliable traffic routing to the services running on the cluster.
Azure Kubernetes Service (AKS) supports the standard NGINX ingress controller and provides the option to configure an ingress accompanied by the Application Gateway Ingress Controller (AGIC) for load-balancing using Azure Application Gateway L7 load balancer.
For configuring ingress with AGIC support, AKS provides a set of annotations prepended with the appgw.ingress.kubernetes.io prefix. Some important annotations include:
Free and open source Software (FOSS) Ingress solutions provide an alternative to cloud vendor-specific Ingress controllers. However, configuring FOSS Ingress can be complex when migrating between cloud providers, due to differences in Ingress controller implementations and cloud-specific requirements. In such scenarios, it's crucial to review the specific configuration options and annotations for the FOSS Ingress controller being used, as well as any additional configuration required by the target cloud provider.
Commonly used FOSS Ingress solutions include Nginx Ingress, Traefik, and Contour, each with its own set of configuration options and annotations. By understanding these options and adopting a standardized approach to FOSS Ingress configuration, you can simplify the migration of your Kubernetes applications across multiple cloud environments.
How Kasten K10 helps with migrating FOSS Ingress objects
Kasten K10 offers a unique feature called Transform Sets that helps you to migrate FOSS Ingress objects with ease. This feature is available starting from Kasten K10 version 5.5.6. Transform Sets provide a way to modify the structure and metadata of the source objects during the migration process. For instance, Kasten K10 offers pre-configured examples of Traefik and NGINX transform sets to simplify migration. The Traefik transform set can change the Ingress class name and annotations to match the Traefik syntax, while the NGINX transform set can remove unsupported annotations, update rules, and preserve annotations that are essential for NGINX.
Additionally, Kasten K10 provides other pre-configured transform sets, such as
, which removes unwanted annotations from the Ingress object during migration. Similarly, the
transform set ensures that any finalizers associated with the Ingress object are removed. These preconfigured transform sets can be customized easily, or new ones can be created to meet specific migration requirements.
More information about 'Transform Sets' can be found here.
In summary, managing Ingress configurations when migrating Kubernetes applications between different cloud providers can be challenging. However, there are various Ingress configuration options available in popular cloud platforms, such as Google Kubernetes Engine, AWS EKS, and AKS.
To simplify the migration of generic FOSS Ingress solutions, Kasten K10 provides export/import actions and transform mechanisms that enable you to modify the necessary specification attributes of a migrated Kubernetes object before restoring it in the target cloud.
When migrating Ingress objects between different cloud providers, you must make adjustments to ensure the objects function correctly on the target cluster. These adjustments include configuring the Ingress controller, updating the TLS certificate, and updating vendor-specific Ingress annotations to reflect the unique features provided by each cloud provider.
By following these adjustments, you can migrate Ingress objects correctly, providing secure and reliable traffic routing to the services running on the target cluster.
Ed is a skilled software engineer with over a decade of industry experience. He brings to the table a strong background in developing storage systems, including an impressive eight-year tenure at Dell EMC. Through this, Ed has honed his expertise in building complex distributed systems and working on various open source projects. He holds a master's degree in Software Engineering from Saint-Petersburg State Electrotechnical University "LETI", which showcases his unwavering commitment to continuous learning and professional growth. Ed's deep understanding of software engineering principles and his ability to navigate intricate technical landscapes make him a valuable member to the Kasten engineering team. As a software engineer at Kasten, Ed actively contributes to shaping the future of data protection and management solutions. His technical skills and adaptability greatly contribute to the company's mission of delivering innovative solutions.
Kasten, Inc. 8800 Lyra Drive, Suite 450 Columbus, Ohio 43240
We value the critical role that the security community plays in helping us protect the confidentiality, integrity, and availability of our software, services, and information. If you have information about security vulnerabilities that affect Kasten software, services, or information, please report it to us via our HackerOne Vulnerability Disclosure Program, or anonymously via this form.