Terminate TLS connections in a Managed Kubernetes cluster for Ingress

Last update: October 05 2026Open in Markdown

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, TLS termination can be configured on a load balancer. TLS termination on a load balancer is available in clusters running Kubernetes version 1.25 and higher. You can upgrade the cluster version.

Certificates can be managed using the Certificate Manager — add your custom certificate or issue a Let’s Encrypt® certificate.

1. Add a custom certificate or issue one in Certificate Manager.
2. Create a load balancer.
3. Edit 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, in 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, check the Add 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, make sure all certificates (the primary certificate for the domain, intermediate certificates, and 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 must match the Subject value of the second intermediate certificate, 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, check the Add 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, in 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 primary domain certificate, click Add additional domain.

   Enter the subdomain name. To issue a Wildcard certificate, enter a subdomain such as *.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 LoadBalancer type Service:

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> — load balancer name;
• <certificate_uuid> — universally unique identifier (UUID) of the certificate copied in the Add or issue certificate instructions;
• <application_name> — application name.

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

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, in the top menu, click Products and select DNS hosting.
2. In the Domain zones section, open the zone page.
3. In the menu of the A record group, select Edit.
4. Change the IP address to the load balancer address. The load balancer IP address can be viewed in the Control panel: in the top menu, click Products and select Cloud Servers → Load Balancers → Load Balancers tab → load balancer card.
5. Click Save.
6. Wait for the DNS record to update on the DNS servers. The update time can take from the record's TTL up to 72 hours. You can view the DNS record TTL in the Control panel: in the top menu, click Products and select DNS hosting → Domain zones → zone page → record row → TTL field.
7. Optional: check the DNS record. If the DNS 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.