Introduction

On GKE, a plain Kubernetes Service does not magically become an HTTPS load balancer just because you expose port 443. If you want Google-managed TLS termination and HTTP(S) load balancing, the usual solution is an Ingress or Gateway that points to a Service. If you only need raw TLS traffic forwarded to pods that already speak HTTPS, a LoadBalancer Service can expose port 443 directly.

Understand What A Service Actually Does

A Kubernetes Service primarily gives stable networking to a set of pods. On GKE, type: LoadBalancer provisions an external load balancer, but by itself it is still a layer 4 style exposure mechanism.

That means:

• it can forward TCP traffic to your pods
• it does not automatically manage certificates for you
• it does not automatically provide the full Google HTTP(S) load balancing feature set

This is why many "enable HTTPS on a Service" questions are really asking for Ingress behavior.

Option 1: Expose An App That Already Serves HTTPS

If your application terminates TLS itself, you can expose port 443 through a LoadBalancer Service.

1apiVersion: v1
2kind: Service
3metadata:
4  name: secure-app
5spec:
6  type: LoadBalancer
7  selector:
8    app: secure-app
9  ports:
10    - name: https
11      port: 443
12      targetPort: 8443

If the pod listens on 8443 with its own certificate, the service can forward external 443 traffic straight through.

A matching deployment might look like this:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: secure-app
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: secure-app
10  template:
11    metadata:
12      labels:
13        app: secure-app
14    spec:
15      containers:
16        - name: app
17          image: your-image:latest
18          ports:
19            - containerPort: 8443

This works, but certificate management and HTTPS behavior live inside your application or sidecar, not in GKE's higher-level HTTP(S) stack.

Option 2: Use Ingress For Managed HTTPS

If you want Google-managed HTTPS termination, URL routing, and certificate integration, use Ingress with a backend Service.

Service:

1apiVersion: v1
2kind: Service
3metadata:
4  name: web-service
5spec:
6  selector:
7    app: web
8  ports:
9    - port: 80
10      targetPort: 8080

Ingress:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web-ingress
5spec:
6  rules:
7    - host: example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: web-service
15                port:
16                  number: 80

Then attach TLS through a Google-managed certificate or your own certificate configuration, depending on the GKE feature set you are using.

In this architecture:

• the Service remains the backend target
• the Ingress handles the HTTPS-facing frontend behavior

This is the usual production-grade answer for browser-facing web apps on GKE.

Why Exposing Port 443 Alone Is Not Enough

A lot of confusion comes from assuming this is enough:

ports:
  - port: 443
    targetPort: 80

That only maps an external port number. It does not create TLS by itself. HTTPS requires certificate handling and TLS negotiation somewhere.

If your pod is not speaking HTTPS and no higher-level load balancer is terminating TLS, traffic on port 443 is just misconfigured TCP.

Port numbers do not create encryption. TLS configuration does.

Choose Based On Where TLS Should Terminate

Ask this question first:

• should TLS terminate at the pod or at Google's load balancer layer

Use a LoadBalancer Service when:

• your app already serves HTTPS itself
• you want TCP forwarding to the pod
• you are not relying on Google HTTP(S) routing features

Use Ingress or Gateway when:

• you want managed certificate handling
• you want host or path routing
• you want Google HTTP(S) load balancing features

That distinction removes most of the ambiguity from this topic.

Common Pitfalls

The biggest mistake is assuming that exposing port 443 on a Service automatically enables HTTPS. It does not.

Another mistake is using a plain LoadBalancer Service when the real requirement is managed TLS termination, redirects, or host-based routing. Those are Ingress or Gateway concerns.

People also forget that if the pod terminates TLS itself, certificate rotation and secret handling become application-side operational work.

Finally, do not mix backend HTTP and frontend HTTPS assumptions carelessly. Be explicit about where encryption starts and ends.

Summary

• A plain GKE Service can expose TCP on port 443, but that alone does not create managed HTTPS.
• If your app already serves TLS, a LoadBalancer Service can forward HTTPS traffic to it.
• For Google-managed HTTPS termination, use Ingress or Gateway in front of the Service.
• Port 443 is only a port number; HTTPS requires real TLS configuration and certificates.
• Decide first where TLS should terminate, then choose Service-only or Ingress-based exposure accordingly.