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.
Ingress Configuration Specifics
Google Kubernetes Engine (GKE)
GKE provides the following kinds of Ingress resource configurations:
- Internal ingress:Requires kubernetes.io/ingress.class: gce-internalannotation
- External ingress: Requires kubernetes.io/ingress.class: gceannotation
- Multi-cloud ingress: Requires separate CRD, thus we won’t cover it in this article
Each ingress type can have a separate set of annotations.
Internal GKE Ingress annotations
- kubernetes.io/ingress.class: gce-internal: Specifies the ingress controller used for the Ingress object
- kubernetes.io/ingress.allow-http: true|false: Enables or disables HTTP protocol for the Ingress object
- ingress.gcp.kubernetes.io/pre-shared-cert: CERT_NAME: specifies the name of the certificate resource to be used for SSL termination
- networking.gke.io/suppress-firewall-xpn-error: true|false: enables or disables firewall error message suppression for cross-project network resources
- kubernetes.io/ingress.regional-static-ip-name: 1.1.1.1: Specifies the regional static IP address for the Ingress object
External GKE Ingress annotations
- kubernetes.io/ingress.class: gce: Specifies the ingress controller used for the Ingress object
- ingress.gcp.kubernetes.io/pre-shared-cert: CERT_NAME: specifies the name of the certificate resource to be used for SSL termination
- networking.gke.io/v1beta1.FrontendConfig: FRONTEND_CONFIG_NAME: specifies the name of the frontend configuration to be used for the Ingress object
- networking.gke.io/suppress-firewall-xpn-error: true|false: enables or disables firewall error message suppression for cross-project network resources
- kubernetes.io/ingress.regional-static-ip-name: 1.1.1.1: Specifies the regional static IP address for the Ingress object
AWS Elastic Kubernetes Service (EKS)
AWS EKS provides a special kind of Ingress resource, which can use the AWS Application Load Balancer (ALB) Ingress controller.
To help configure Ingress with the ALB Ingress Controller, AWS EKS provides a huge set of annotations prepended with alb.ingress.kubernetes.io prefix. The whole set of supported annotations can be found here.
Along with ALB Ingress support, AWS EKS allows for the configuration of a standard NGINX Ingress controller, which doesn’t require any specific annotations.
Azure Kubernetes Service (AKS)
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:
- appgw.ingress.kubernetes.io/backend-address-pool-name: Specifies the name of the Application Gateway backend pool to use for the ingress controller
- appgw.ingress.kubernetes.io/ssl-redirect: Specifies whether HTTPS redirection is enabled on the Application Gateway instance. Values can be “true” or “false”
- appgw.ingress.kubernetes.io/cookie-based-affinity: Specifies whether to use cookie-based affinity for client affinity. Values can be “true” or “false”
- appgw.ingress.kubernetes.io/appgw-additional-match-condition: Allows for additional match conditions to be added to the Application Gateway
- appgw.ingress.kubernetes.io/rewrite-rule-set-name: Specifies the name of the Application Gateway rewrite rule set to use for the ingress controller
The complete set of supported annotations for AGIC can be found in the official Azure documentation.
FOSS Ingress Controllers
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.
Full list of well-known FOSS Ingress solutions.
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 remove-ingress-annotations-example, which removes unwanted annotations from the Ingress object during migration. Similarly, the remove-ingress-finalizers-example 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.
Conclusion
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.
New to Kasten K10? Try it for free today!
