Terminate TLS connections in a Managed Kubernetes cluster for Ingress

Last update: May 30 2026

TLS termination for a Managed Kubernetes cluster is the process of decrypting HTTPS traffic and redirecting it to the Kubernetes pods as HTTP traffic.

TLS termination can be used for:

• securing data transfer between the client and the service in the cluster;
• controlling access to services in the cluster and protecting against unauthorized access;
• improving performance;
• simplifying certificate management.

In a Managed Kubernetes cluster, you can configure TLS termination on the load balancer. TLS termination on the load balancer is available in clusters with Kubernetes version 1.25 and higher. You can upgrade the cluster version.

You can manage certificates via the Certificate Manager — add your custom certificate or issue a Let’s Encrypt® certificate.

1. Add a custom certificate or issue one in the Certificate Manager.
2. Create a load balancer.
3. Update the domain's A record.

1. Add or issue a certificate

In the Certificate Manager, you can upload a certificate issued by third-party certificate authorities or issue a Let’s Encrypt® certificate.

Add a certificate

1. In the Control panel, on the top menu, click Products and select Certificate Manager.

2. In the Certificates section, click Add certificate.

3. Select Custom certificate.

4. Enter a certificate name.

5. Paste the primary certificate for the domain. It must start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

6. Paste the private key. It must start with -----BEGIN PRIVATE KEY----- and end with -----END PRIVATE KEY-----.

7. Optional: to add an intermediate certificate, select the Add an intermediate certificate checkbox and paste the certificate into the Intermediate certificate field. It must start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

   If you need to add multiple intermediate certificates, ensure that all certificates (the primary domain certificate, intermediate certificates, and the root certificate) form a complete chain. The Issuer value of the primary certificate must match the Subject value of the first intermediate certificate, the Issuer value of the first intermediate certificate — with the Subject of the second intermediate and so on.

   Intermediate certificates can be added to the Intermediate certificate field in any order, it is important to use the full chain.

8. Optional: to add a root certificate, select the Add a root certificate checkbox and paste the certificate into the Root certificate field. It must start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

9. Click Add.

10. Open the certificate page.

11. Copy the certificate UUID.

Issue a Let’s Encrypt® certificate

You can issue a Let’s Encrypt® certificate that is valid for:

• the primary domain only, or the primary domain and all its subdomains (Wildcard certificate);
• a subdomain only. The certificate will not be valid for the primary domain.

1. Create a zone for the domain or subdomain.

2. Delegate the domain or subdomain.

3. In the Control panel, on the top menu, click Products and select Certificate Manager.

4. In the Certificate Manager * section, click Add certificate.

5. Select Let’s Encrypt® certificates.

6. Enter a certificate name.

7. Select the domain or subdomain you delegated to DNS hosting in step 2.

8. Optional: to add a subdomain to the certificate for the primary domain, click Add additional domain.

   Enter the subdomain name. To issue a Wildcard certificate, enter a subdomain in the format *.example.com.

9. Click Issue certificate.

10. Open the certificate page.

11. Copy the certificate UUID.

12. In the Certificate Files block, select the certificate, intermediate certificate chain, root certificate, and private key.

13. Click Download.

14. Install the certificate on your service side.

2. Create a load balancer

Create a manifest with a Service of type LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: <loadbalancer_name>
  annotations:
    loadbalancer.openstack.org/default-tls-container-ref: "<certificate_uuid>"
spec:
  type: LoadBalancer
  selector:
    app: <application_name>
  ports:
  - port: 443
    protocol: TCP
    targetPort: 80
    name: https

Specify:

• <loadbalancer_name> — the load balancer name;
• <certificate_uuid> — the universal unique identifier (UUID) of the certificate you copied in the Add or issue a certificate instruction;
• <application_name> — the application name.

The created load balancer will appear in the Control panel: in the top menu, click Products and select Cloud Servers → Load Balancers → tab Load Balancers.

3. Update the domain's A record

You can speed up the propagation of resource record changes to caching servers. To do this, reduce the record TTL to the lowest possible value a few days before the planned change. Then, change the resource record at the scheduled time, and once the change has propagated to the caching servers, revert the TTL to its previous value.

1. In the Control panel, on the top menu, click Products and select DNS Hosting.
2. In the Domain Zones section, open the zone page.
3. In the menu for the A record group, select Edit.
4. Change the IP address to the load balancer address. You can view the load balancer IP address in the Control panel: in the top menu, click Products and select Cloud Servers → Load Balancers → tab Load Balancers → load balancer card.
5. Click Save.
6. Wait for the resource record to be updated on the DNS servers. The update time can take from the record TTL up to 72 hours. You can view the resource record TTL in the Control panel: in the top menu, click Products and select DNS Hosting → Domain Zones → zone page → record row → field TTL.
7. Optional: check the resource record. If the resource record has not updated after 72 hours, create a ticket.
8. Ensure that requests are only going to the load balancer and that there are no user requests hitting the server.