Multi-cluster GKE
1. Multi-cluster GKE
GKE provides a robust infrastructure for deploying developer platforms. Let's explore the key elements that form this infrastructure when building multi-cluster environments. Enterprise infrastructure can be complex, so let's start with a small example and scale it up to a size that would use the benefits of GKE. Let's begin by examining the structure of a single environment for developers. This example displays the production environment, but if there were other environments in the infrastructure, like non-production or development environments, they would have the same structure. Each environment includes resources for fleet configuration and a group of one or more clusters, typically distributed across regions. In this infrastructure, Cloud Load Balancing distributes application traffic across regions to Kubernetes service objects. Behind each service is a logical grouping of related pods working together to provide the application's functionality. As your Kubernetes environments grow and become more complex, it can be challenging to manage communication between microservices Cloud Service Mesh provides a dedicated infrastructure layer that controls and secures traffic flow between your services, ensuring smooth and reliable communication. Remember that complex environments need resource management. As your architecture scales, another consideration is resource management and optimization. GKE uses a combination of namespaces and tenants to divide and group resources. Namespaces provide a fundamental way to divide a cluster into multiple virtual clusters. Each namespace can have its own resource quotas and limits, which control the amount of CPU, memory, and other resources that workloads within that namespace can consume. This allows for resource isolation between different teams or applications. In Kubernetes, tenants serve as an abstraction to represent multiple users and workloads, each with different permissions and roles. They provide a way to logically group and isolate services, ensuring secure multi-tenancy and resource management. In Kubernetes, tenants are implemented as namespaces. In this example, each cluster has number of tenants for grouping services. There is a tenant pipeline for allocating and balancing resources for tenant request. Namespaces are used to split clusters into workloads. Each Kubernetes service is built and deployed using its own dedicated pipeline. That same pipeline is used to deploy the service to the development, non-production, and production environments. Other elements are common across all environments, like Cloud Logging and Cloud Monitoring. The GKE fleet architecture reduces management overhead by reinforcing the concepts of sameness and trust. When designing an enterprise application, Google Cloud suggests the following architecture blueprint for reference. You have four projects for the infrastructure, including the common resources, production, non-production, and development. In the common infrastructure project, you host and configure tools like Cloud Build, Artifact Registry, and Cloud Deploy. These can be used across different environments, providing a consistent way to build, store, and deploy your applications. In the production, non-production, and development infrastructure projects, you have the resources that will be used in each environment. For example, for production, you might have two clusters to cover high availability and disaster recovery use cases, while in development, a single cluster for testing might be enough. Additionally, in each environment, you will also host adjacent Cloud Services, like Cloud Monitoring and Cloud Logging. The infrastructure team will be responsible for setting this up. Next, you have your application teams. They will deploy their Kubernetes-based applications to a namespace in each cluster, but won't have access to perform any changes in the infrastructure, such as increasing the size of the cluster or creating new clusters. They will be responsible for interacting only with resources within the cluster. That way, you have a clear separation of responsibilities between infrastructure and development teams.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.