Catalog
google/gke-service-networking

google

gke-service-networking

Configures GKE edge networking, traffic routing, load balancing, and private service endpoints. Use when configuring Gateway API manifests, standard Ingress, Cloud Armor WAF security policies, Container-Native Load Balancing (NEGs), Private Service Connect (PSC), or Google-managed SSL certificates on GKE. Don't use for core cluster IP planning, Dataplane V2 network policies, or node NAT egress (use gke-networking instead).

global
New~1.5k
v1.0Saved Jul 24, 2026

GKE Service Networking Skill

This skill provides workflows for exposing applications running on GKE securely to the internet or internal networks.

Workflows

The Gateway API is the modern way to manage routing in Kubernetes.

Prerequisites: Gateway API must be enabled on the cluster (enabled by default in GKE 1.24+).

Example Gateway Manifest:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: {gateway_name}
  namespace: {namespace}
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE managed external L7 load balancer
  listeners:
    - name: http
      protocol: HTTP
      port: 80

Example HTTPRoute Manifest:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: {route_name}
  namespace: {namespace}
spec:
  parentRefs:
    - name: {gateway_name}
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: {service_name}
          port: 80

2. Configure Standard GKE Ingress

Use standard Ingress for simpler use cases or legacy setups.

Example Ingress Manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {ingress_name}
  namespace: {namespace}
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {service_name}
                port:
                  number: 80

3. Secure with Cloud Armor

Cloud Armor provides WAF and DDoS protection.

Enable Cloud Armor via BackendConfig:

  1. Create a Security Policy in Cloud Armor (usually via gcloud or Terraform).
  2. Reference it in a BackendConfig in GKE.

Example BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: {backend_config_name}
  namespace: {namespace}
spec:
  securityPolicy:
    name: {security_policy_name}
  1. Associate BackendConfig with your Service via annotations:

    # In your Kubernetes Service manifest metadata.annotations:
    cloud.google.com/backend-config: '{"default": "{backend_config_name}"}'
    # Or for specific port mappings:
    cloud.google.com/backend-config: '{"ports": {"80": "{backend_config_name}"}}'
    

4. Configure Google-Managed SSL Certificates

Automatically provision and renew SSL certificates.

Example ManagedCertificate (Legacy Ingress):

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: {certificate_name}
spec:
  domains:
    - {domain_name}

Reference it in Ingress annotations: networking.gke.io/managed-certificates: {certificate_name}.

Gateway API Approach: For standard Certificate Manager integration, create a CertificateMap and reference it directly in the Gateway metadata annotations using networking.gke.io/cert-map: {certificate_map_name}, or reference a Kubernetes Secret in the HTTPS listener:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: {gateway_name}
  namespace: {namespace}
  annotations:
    networking.gke.io/cert-map: {certificate_map_name} # For Certificate Manager maps
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: {secret_name} # Or directly reference a Kubernetes Secret

Container-native load balancing allows load balancers to target Kubernetes Pods directly, rather than targeting nodes. This improves latency and distribution.

Prerequisites: Cluster must be VPC-native.

How it works:

  • For GKE Ingress and Gateway API, container-native load balancing is enabled by default via Network Endpoint Groups (NEGs).
  • To verify or explicitly enable it for a Service, use the cloud.google.com/neg annotation.

Example Service Manifest:

apiVersion: v1
kind: Service
metadata:
  name: {service_name}
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Enabled for Ingress
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  selector:
    app: {app_name}
  type: ClusterIP

6. Configure Private Service Connect (PSC)

Private Service Connect allows you to expose services in one VPC to consumers in another VPC securely, without VPC peering.

Steps:

  1. Create an internal load balancer for your service.
  2. Create a ServiceAttachment referencing the load balancer.

Example ServiceAttachment Manifest:

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: {attachment_name}
  namespace: {namespace}
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
    - {nat_subnet_name} # Subnet dedicated for PSC NAT
  resourceRef:
    kind: Service
    name: {service_name}

Share the ServiceAttachment URI with consumers to create a PSC endpoint in their VPC.

Best Practices

  1. Prefer Gateway API: It offers more flexibility and role separation than Ingress.
  2. Enable Cloud Armor: Always protect public-facing endpoints with Cloud Armor.
  3. Use Managed Certificates: Avoid managing certificate renewals manually.
  4. Use Container-Native Load Balancing: Always use NEGs for HTTP(S) load balancing to reduce latency and improve traffic distribution.
Files1
1 files · 11.1 KB

Select a file to preview

Overall Score

78/100

Grade

B

Good

Safety

88

Quality

75

Clarity

82

Completeness

68

Summary

A comprehensive guide for configuring GKE service networking through Gateway API, Ingress, Cloud Armor, SSL certificates, container-native load balancing, and Private Service Connect. The skill provides templated YAML manifests and step-by-step workflows for exposing and securing Kubernetes applications on Google Cloud.

Detected Capabilities

Kubernetes manifest generationGKE service configuration guidanceYAML templating with placeholder substitution

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

gke load balancergateway apicloud armor setupmanaged ssl certificategke ingressprivate service connect

Referenced Domains

External domains referenced in skill content, detected by static analysis.

www.apache.org

Use Cases

  • Deploy external or internal load balancers to expose GKE applications
  • Configure Gateway API for modern Kubernetes traffic routing with role separation
  • Implement Cloud Armor WAF policies to protect public-facing services from attacks
  • Set up automatic SSL/TLS certificate provisioning and renewal with Google-managed certificates
  • Enable container-native load balancing (NEGs) for improved latency and traffic distribution
  • Create private service endpoints using Private Service Connect across VPCs without peering

Quality Notes

  • Clear workflow organization with six distinct, well-separated use cases
  • YAML examples provided for each major approach (Gateway API, Ingress, BackendConfig, etc.)
  • Best practices section reinforces recommended patterns (Gateway API over Ingress, Cloud Armor adoption, managed certificates)
  • Scope boundaries are well-defined — the skill explicitly excludes core cluster IP planning, Dataplane V2 network policies, and node NAT egress
  • Placeholders consistently use curly braces (e.g., {gateway_name}, {namespace}) making substitution clear
  • Good progressive disclosure: flows from modern (Gateway API) to legacy (standard Ingress) approaches
  • Missing: step-by-step operational instructions (e.g., 'run kubectl apply -f manifest.yaml'); this reads as a reference guide rather than task instructions
  • Missing: error handling or troubleshooting guidance (e.g., what to do if a ManagedCertificate fails to provision)
  • Missing: edge cases (e.g., domain validation failures, certificate renewal delays, traffic shaping limits)
  • No guidance on validating or testing configurations after deployment
  • Certificate Manager integration in Gateway API section is somewhat dense and could benefit from separate workflow treatment
Model: claude-haiku-4-5-20251001Analyzed: Jul 24, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Use google/gke-service-networking in your dev environment

Command Palette

Search for a command to run...