Fleet Solutions
1. Fleet Solutions
GKE fleets are useful for grouping, sameness, exclusivity, and trust. Let's explore a few examples of how fleets provide a management solution for complex Kubernetes environments. Let's say there are four clusters, two for production in two regions for redundancy, one for staging and testing, and one for development. The development environment is hosted on-premises. A platform team centrally owns and administers all four clusters. There are also two services, frontend and backend. More complex scenarios may include more services and clusters. The platform team is responsible for managing the mesh and establishing trust between the frontend and backend teams. If trust cannot be achieved, two separate meshes could be connected, but this would result in additional management overhead. When considering possible implementations, it's important to determine what should be prioritized, isolation between different resource types or consistency across them? More consistency is easier to achieve with fewer fleets. Let's examine three potential fleet implementations. One approach is to create separate fleets for production, staging, and development resources. Start by creating three separate fleet host projects. You can then add resources to the projects. If a cluster is on-premises, like the development cluster in this example, register it to the dev host project in GKE. Because this is a granular example, there are not many namespace and service sameness concerns to address. However, the prod-east and prod-west clusters are normalized. The advantage of this approach is that there is strong isolation between each of the fleets. The main drawback is that all three fleets need to be administered, so it's difficult to achieve consistency between production, staging, and development. The development team might also have difficulty developing in a staged service environment. Another option is to keep your resources in the example project and create the fleet there. With this approach, namespaces and services must be normalized throughout the fleet, making it easy to achieve consistency across environments. In this example, the generic frontend is renamed to frontend-prod and frontend-staging in the production and staging clusters. While you could keep the original names, it's helpful to rename your namespaces to indicate that they are for development, like frontend-dev-alice in this example. This approach trades isolation for consistency and ease of management. Cloud Service Mesh is used for authorization and preventing unwanted communication, which can be cumbersome and prone to misconfigurations. You can also apply policies across all resources to ensure that development closely reflects production. The final approach we'll explore combines the staging and development resources into a non-production fleet and places production resources in a separate fleet. This option represents the middle ground between isolation and consistency. Resources for production are placed in the production fleet host project and the on-premises development cluster is registered into the non-production fleet. For clarity, namespaces and services can be normalized between the staging and development resources. For example, frontend is renamed to frontend-staging in the staging cluster. The advantage of this solution is that production and non-production are isolated from each other. This allows developers to test their services against staged versions. For example, Alice can connect her frontend service to a staged backend during development. The disadvantage is that the environments are different.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.