Google Distributed Cloud brings public-cloud-like networking to air-gapped environments

Organizations in highly regulated industries often struggle to balance the rigid security of air-gapped environments with the need for the agility and flexibility that the cloud provides. To address this, Google Distributed Cloud (GDC) air-gapped 1.15 introduces new networking features in preview that give you more direct control and visibility without compromising your security posture, as well as a new IPAM feature in general availability that simplifies subnet management. These preview features are Cloud NAT, enhanced connectivity for standard clusters, and advanced HTTP and HTTPS health checks in load balancers. Together, they make it easier for you to manage complex workloads in a secure environment. 

Manage outbound traffic with Cloud NAT

Cloud NAT for GDC air-gapped replaces previous egress solutions and gives you more control over how your instances communicate with other networks, on par with public cloud functionality. Cloud NAT provides several benefits:

• Configurable egress IPs: You can assign and manage multiple egress IP addresses for your outbound traffic so you can identify exactly which workloads are communicating.

• Customizable timeouts: Manage connection lifecycles by adjusting timeouts for different types of traffic.

• Granular control: Administrators can create specific subnets for egress IPs, while application operators define how pods and VMs route their traffic.

Connect standard clusters directly to your organization

In a secure environment, isolation should not result in disconnected silos. With the latest release, standard clusters include networking updates that help you communicate across your organization while maintaining strict security boundaries, helping you manage your environment more effectively. The updates include:

• Direct pod communication: Your standard cluster pods can now communicate directly with workloads in your organization’s Default VPC. This simplifies how you connect standard clusters and shared clusters.

• Flexible firewall policies: You can use both Project Network Policy and Kubernetes Network Policy APIs to set granular rules for traffic entering and leaving your pods and nodes.

• Managed load balancing: You can create internal and external load balancers using standard Kubernetes Service APIs, while GDC manages the underlying configuration for you.

Pods within a standard cluster can now connect to other pods directly or through a ClusterIP. While traffic to the Infra VPC remains blocked, you can send traffic to shared cluster workloads through GDC internal load balancers. This ensures your applications can reach necessary services quickly.

Improve reliability with Load Balancer HTTP and HTTPS health checks

Previously, L4 load balancing health checks only monitored basic TCP connectivity, only confirming if a port was open. GDC air-gapped load balancers now support HTTP and HTTPS health checks, which allow you to verify if an application is actually functioning correctly. By checking status codes and response content, you can:

• Confirm application health: Verify that services are responding correctly, not just that the server is powered on.

• Increase reliability: Automatically detect and route traffic away from applications experiencing internal errors.

• Improve visibility: Access better data regarding the health of your VM-based workloads to manage performance before issues arise.

Make subnet management easier with subnet groups

Previously, a child subnet could only reference a single parent subnet. With the introduction of the subnet group, a child subnet can now reference a subnet group that may contain multiple parent subnets. This provides the following benefits:

• Overcome the challenges of immutable subnet CIDR: While subnet CIDR range is immutable, subnet group simplifies scaling up IP resources by attaching a new subnet to a subnet group. You can reference a subnet group instead of a single parent subnet for easy scale-up.
• Automatically identify a parent subnet: Now you can reference a subnet group as parent rather than as a single subnet. By using a subnet group in this way, you don't need to manually identify a parent subnet that has available IP resources: instead, GDC IPAM automatically finds a subnet in the subnet group with enough available IP space as its parent.
• Start with smaller CIDRs for easier planning: Using subnet groups to scale IP resources also means that you can start with smaller and discontinuous CIDRs when creating new parent subnets, making IP resource utilization more efficient and the planning process easier.

Get started

To learn more about these features, please refer to our documentation or contact your Google Cloud account team.