Exposing Applications

Kubernetes workloads can be exposed to each other, and to the public using Services and Ingresses. A Service allocates a dedicated IP for the exposed application, whereas an Ingress works for HTTP based protocols and alleviates the need for a separate IP for each endpoint. For stateless web-services, using the Serverless framework is another option where the application is deployed with a TLS enabled hostname and auto-scaling for you.
Internal Services
Internal, cluster local services should be configured as regular ClusterIP services.
Public Services
Exposing services to the Internet is done by deploying a LoadBalancer service type with an annotation to allocate a public IP for the service. Without the annotation, a static private IP will be allocated, this is mostly useful for services accessed from outside the cluster via a Site to Site VPN.
Depending upon where you've requested your workloads to run, public IP pools are accessible via the region location in the following manner:
Region
Address Pool Label
ORD1
public-ord1
EWR1
public-ewr1
LAS1
public-las1
sshd-public-service.yaml
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  annotations:
5
    metallb.universe.tf/address-pool: public-ord1
6
    metallb.universe.tf/allow-shared-ip: default
7
  name: sshd
8
spec:
9
  type: LoadBalancer
10
  externalTrafficPolicy: Local
11
  ports:
12
    - name: sshd
13
      port: 22
14
      protocol: TCP
15
      targetPort: sshd
16
  selector:
17
    app.kubernetes.io/name: sshd
Copied!
For public services, ensure that externalTrafficPolicy: Local is set on the service. This load balances ingress traffic from the Internet directly to the  nodes running the  application.
Attaching Service IP directly to Pod
The traditional Kubernetes pattern is one or many Pods with dynamic internal IPs exposed behind a Service or Ingress with a static IP. For certain use cases, where there would only be one Pod behind a service, it can make sense to attach the Service IP directly to the Pod. A Pod would then have a static public IP as it's Pod IP. All connections originating from the pod will have this IP as it's source, and the Pod will see this as it's local IP. This is a non standard approach for containers, and should be used only when the traditional Service / Pod pattern is not feasible. Directly attaching the Service IP is beneficial in the following scenarios:
The application needs to expose a large number of ports (above 10), where listing them out in the service definition is impractical
The application needs to see the service IP on the network interface inside the pod
Connections originating from the Pod to the outside need to originate from the Service IP
The application needs to receive all traffic regardless of type and port
A Virtual Machine type workload where a static IP provides a more native experience
Please note that an application that directly attaches a Service IP can run with a maximum of 1 replica, as there would otherwise be multiple Pods with the same Pod IP. Traffic to the Pod will not be filtered, all inbound traffic to the IP will be sent to the pod. To provide security, NetworkPolicies can be applied.
A stub Service needs to be created to allocate the IP. The Service should expose only port 1 as in the example below.
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: my-app
5
  annotations:
6
    metallb.universe.tf/address-pool: public-ord1
7
spec:
8
  externalTrafficPolicy: Local
9
  type: LoadBalancer
10
  ports:
11
    - port: 1 # Do not change this
12
      targetPort: attach
13
      protocol: TCP
14
      name: attach
15
     # Do not add any additional ports, it is not required for direct attach
16
  selector: 
17
    coreweave.cloud/ignore: ignore # Do not change this
Copied!
To attach the IP from the Service directly to a Pod, annotate the Pod spec.
1
  annotations:
2
    net.coreweave.cloud/attachLoadbalancerIP: my-app
Copied!
Ingress
Using an Ingress for HTTP based applications are beneficial as it saves IP addresses and automatically provides a DNS name as well as TLS certificate to allow access to your application via https. CoreWeave already has all the infrastructure setup including the Ingress Controller, all you need to do is deploy an Ingress manifest. The hostname of the Ingress needs to be in the format of <app>.<namespace>.<region>.ingress.coreweave.cloud. The example below demonstrates an Ingress called my-app exposed via an Ingress in the ORD1 region for a namespace tenant-test-default.
1
apiVersion: networking.k8s.io/v1beta1
2
kind: Ingress
3
metadata:
4
  annotations:
5
    cert-manager.io/cluster-issuer: letsencrypt-prod
6
    ingress.kubernetes.io/force-ssl-redirect: "true"
7
    ingress.kubernetes.io/ssl-redirect: "true"
8
    traefik.ingress.kubernetes.io/redirect-entry-point: https
9
  labels:
10
    app.kubernetes.io/name: my-app
11
  name: my-app
12
spec:
13
  rules:
14
  - host: my-app.tenant-test-default.ord1.ingress.coreweave.cloud
15
    http: 
16
      paths:
17
      - backend:
18
          serviceName: my-app
19
          servicePort: http
20
        path: /
21
        pathType: ImplementationSpecific
22
  tls:
23
  - hosts:
24
    - my-app.tenant-test-default.ord1.ingress.coreweave.cloud
25
    secretName: my-app-tls # This secret is automatically created for you
Copied!
​

CoreWeave Kubernetes - Previous

Storage

Next - CoreWeave Kubernetes

Serverless

Last modified 1mo ago

Copy link

Contents

Internal Services

Public Services

Attaching Service IP directly to Pod

Ingress