GKE Topologies
Scenario 1 - For an upcoming Google Kubernetes Engine (GKE) cluster, the current cluster size is expected to host 10 nodes, with 20 Pods per node and 150 services. Because of the migration of new services over the next 2 years, there is a planned growth for 100 nodes, 200 Pods per node, and 1500 services. You want to use VPC-native clusters with alias IP ranges, while minimizing address consumption.
Recommended Design
- Create a subnet of size /25 (100 plus hosts). 2 Secondary Ranges -/17 (20000) for Pods and /21 (1500) for Services.
- Create a VPC Native Cluster with those subnet ranges
Scenario 2 - To use a Cloud Armor policy for an application that is deployed in Google Kubernetes Engine (GKE). Which GKE resource should you use?
Recommended Design
- In a GKE cluster, incoming traffic is handled by external HTTP(S) Load Balancing, which is a component of Cloud Load Balancing.
- Typically, the HTTP(S) load balancer is configured by the GKE Ingress controller, which gets configuration information from a Kubernetes Ingress object. Google Cloud Armor security policies support the following: IP deny and allow lists Region code deny and allow (beta)
- Pre-configured rules to mitigate cross-site scripting (XSS) and SQL injection (SQLi) attacks (beta)
Need a hands-on, GCP Consultant?
Need help with your GCP journey? Start the conversation today.
Leave a Reply