How to publish an application (Services/Ingress)

Publishing applications inside and outside the cluster.

Publishing an application in Kubernetes usually follows the chain workload → Service → Ingress. The workload runs application pods, Service gives them a stable access point, and Ingress exposes HTTP/HTTPS access from outside the cluster.

If the application has not yet been deployed, first create a Deployment, StatefulSet or other workload type according to the instructions How to deploy an application.

How to choose an access method #

Service #

Ingress #

In the Kubernetes model, each Pod gets its own IP address, but the Pod can be recreated. Service hides this variability behind a stable IP address or DNS name, and Ingress routes external HTTP/HTTPS traffic to the Service.

What to prepare before publishing #

Before creating Service and Ingress, check:

1. The workload is deployed and pods reach Running / Ready.
2. Pods have stable labels by which the Service can select backend pods, for example app: my-app.
3. The container port on which the application receives traffic is known, for example 8080.
4. The user has the rights to create Service, Ingress and, if necessary, Secret in the desired namespace.
5. For external access, the Ingress Controller and access to its IP address, VIP, NodePort or balancer are configured. For more information about traffic flow, see Architectural diagrams of cluster networks.
6. A DNS record is configured for access by domain name. Before setting up DNS, you can check Ingress with a request with the Host header.
7. TLS Secret of type kubernetes.io/tls has been prepared for HTTPS with keys tls.crt and tls.key.

You can create Service and Ingress from the Networks section in the namespace or from the namespace dashboard, which displays the relationship between workloads, services and ingresses. For more details, see Namespace dashboard review.

Step 1. Create a Service #

Service defines a logical set of pods and the access policy for them. For an application with labels app: my-app, the Service must use the same selector, otherwise the traffic will not get to the right pods.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  namespace: my-namespace
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

apiVersion: v1
kind: Service
metadata:
  name: external-api
  namespace: my-namespace
spec:
  type: ExternalName
  externalName: api.example.com

kubectl expose deployment my-app \
  --name my-app-service \
  --port 80 \
  --target-port 8080 \
  -n my-namespace

kubectl apply -f service.yaml

kubectl get svc my-app-service -n my-namespace
kubectl describe svc my-app-service -n my-namespace
kubectl get endpointslices -n my-namespace -l kubernetes.io/service-name=my-app-service

Step 2. Configure TLS Secret #

For HTTPS Ingress needs Secret containing the private key and TLS certificate. The Secret must contain the keys tls.crt and tls.key, and the certificate must match the domain name under which the application is published.

Ingress uses TLS on port 443 and terminates the TLS connection at the entry point. Traffic from Ingress to Service and pods is then transferred as internal cluster traffic. If multiple hosts are specified in the tls section, they are processed on the same port using SNI. Hosts in tls.hosts must explicitly match hosts in rules.

apiVersion: v1
kind: Secret
metadata:
  name: my-app-tls
  namespace: my-namespace
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>

kubectl create secret tls my-app-tls \
  --cert=./tls.crt \
  --key=./tls.key \
  -n my-namespace

kubectl get secret my-app-tls -n my-namespace

Step 3: Create an Ingress #

Ingress controls external access to services in the cluster. It defines HTTP/HTTPS routes from outside the cluster to a Service inside the cluster, and can use load balancing, TLS, and name-based virtual hosting.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: my-namespace
spec:
  tls:
    - hosts:
        - my-app.example.com
      secretName: my-app-tls
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

spec:
  ingressClassName: nginx

kubectl create ingress my-app-ingress \
  --namespace=my-namespace \
  --class=nginx \
  --rule="my-app.example.com/*=my-app-service:80,tls=my-app-tls"

kubectl get ingress my-app-ingress -n my-namespace
kubectl describe ingress my-app-ingress -n my-namespace

curl -H "Host: my-app.example.com" http://<INGRESS_IP>/

Complete example of publishing an application #

In the example, Deployment creates pods with label app: my-app, Service selects these pods through a selector, and Ingress directs external traffic on host my-app.example.com to Service my-app-service.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: registry.example.com/my-app:v1.0.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  namespace: my-namespace
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: my-namespace
spec:
  tls:
    - hosts:
        - my-app.example.com
      secretName: my-app-tls
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

Application and basic check:

kubectl apply -f publish-my-app.yaml

kubectl get deploy,po,svc,ingress -n my-namespace
kubectl describe svc my-app-service -n my-namespace
kubectl describe ingress my-app-ingress -n my-namespace

Checking access within the cluster:

kubectl run curl-test --rm -it \
  --image=curlimages/curl \
  --restart=Never \
  -n my-namespace \
  -- curl http://my-app-service.my-namespace.svc.cluster.local

Checking external access:

# Before DNS configuration
curl -H "Host: my-app.example.com" http://<INGRESS_IP>/

# After DNS and TLS configuration
curl https://my-app.example.com

Testing and diagnostics #

Service #

If the application is not available through Service, check:

1. The service is created in the same namespace where the application pods are located.
2. spec.selector Service matches the labels of the pods.
3. port Service and targetPort of the container correspond to the real ports of the application.
4. Service now has EndpointSlice for backend pods. The backend pod must be in the Running and Ready=true state, otherwise the endpoint will not get into the Service.
5. The correct DNS name is used inside the cluster: <service-name>.<namespace>.svc.cluster.local. In the same namespace you can use the short name Service.

kubectl get svc -n my-namespace
kubectl describe svc my-app-service -n my-namespace
kubectl get pods -n my-namespace --show-labels
kubectl get endpointslices -n my-namespace -l kubernetes.io/service-name=my-app-service

Ingress #

If Ingress does not open the application, check:

1. Ingress Controller is installed and its pods are running.
2. Service has backend pods.
3. host, path, pathType, backend Service and port in Ingress are specified correctly.
4. The DNS record points to the IP address, VIP, NodePort, or Ingress Controller balancer.
5. For HTTPS Secret exists in the same namespace, contains tls.crt and tls.key, and the certificate is issued to the required FQDN.
6. Check that there are no errors in Ingress and Pod events.

kubectl get ingress -n my-namespace
kubectl describe ingress my-app-ingress -n my-namespace
kubectl get events -n my-namespace --sort-by='.lastTimestamp'

For detailed commands for checking Ingress Controller, Service and controller logs, see the section Troubleshooting Networks. Frequent application problems are described in Workload troubleshooting.

Network policies #

If network policies are enabled in the cluster, they can block traffic from the Ingress Controller to the backend pods. Allow incoming traffic from the Ingress Controller to the application. For an example policy, see Allow incoming traffic from Ingress Controller.

Recommendations #

• For internal dependencies between applications, use ClusterIP and the DNS name Service.
• For production publishing of HTTP/HTTPS applications, use Ingress with a domain name and TLS.
• LoadBalancer use when you need direct external IP without HTTP/HTTPS routing at the Ingress level.
• NodePort use for testing or special infrastructure scenarios.
• Do not store private keys and certificates in public manifests. Use Kubernetes Secrets.

Additional materials #

• How to deploy an application - creation and verification of workload before publication.
• Namespace dashboard overview — how to see connections between Routes, Services, and Workloads.
• Import manifests - loading YAML without kubectl.
• ClusterIssuer and Issuer - issue certificates through cert-manager.
• How to connect a private registry - preparing access to application images.
• Network Troubleshooting - checking Ingress, Service and network access.