tencent cloud

Tencent Kubernetes Engine

Release Notes and Announcements
Release Notes
Announcements
Release Notes
Product Introduction
Overview
Strengths
Architecture
Scenarios
Features
Concepts
Native Kubernetes Terms
Common High-Risk Operations
Regions and Availability Zones
Service Regions and Service Providers
Open Source Components
Purchase Guide
Purchase Instructions
Purchase a TKE General Cluster
Purchasing Native Nodes
Purchasing a Super Node
Getting Started
Beginner’s Guide
Quickly Creating a Standard Cluster
Examples
Container Application Deployment Check List
Cluster Configuration
General Cluster Overview
Cluster Management
Network Management
Storage Management
Node Management
GPU Resource Management
Remote Terminals
Application Configuration
Workload Management
Service and Configuration Management
Component and Application Management
Auto Scaling
Container Login Methods
Observability Configuration
Ops Observability
Cost Insights and Optimization
Scheduler Configuration
Scheduling Component Overview
Resource Utilization Optimization Scheduling
Business Priority Assurance Scheduling
QoS Awareness Scheduling
Security and Stability
TKE Security Group Settings
Identity Authentication and Authorization
Application Security
Multi-cluster Management
Planned Upgrade
Backup Center
Cloud Native Service Guide
Cloud Service for etcd
TMP
TKE Serverless Cluster Guide
TKE Registered Cluster Guide
Use Cases
Cluster
Serverless Cluster
Scheduling
Security
Service Deployment
Network
Release
Logs
Monitoring
OPS
Terraform
DevOps
Auto Scaling
Containerization
Microservice
Cost Management
Hybrid Cloud
AI
Troubleshooting
Disk Full
High Workload
Memory Fragmentation
Cluster DNS Troubleshooting
Cluster kube-proxy Troubleshooting
Cluster API Server Inaccessibility Troubleshooting
Service and Ingress Inaccessibility Troubleshooting
Common Service & Ingress Errors and Solutions
Engel Ingres appears in Connechtin Reverside
CLB Ingress Creation Error
Troubleshooting for Pod Network Inaccessibility
Pod Status Exception and Handling
Authorizing Tencent Cloud OPS Team for Troubleshooting
CLB Loopback
API Documentation
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
FAQs
TKE General Cluster
TKE Serverless Cluster
About OPS
Hidden Danger Handling
About Services
Image Repositories
About Remote Terminals
Event FAQs
Resource Management
Service Agreement
TKE Service Level Agreement
TKE Serverless Service Level Agreement
Contact Us
Glossary
DokumentasiTencent Kubernetes EngineUse CasesNetworkDNSImplementing Custom Domain Name Resolution in TKE

Implementing Custom Domain Name Resolution in TKE

PDF
Mode fokus
Ukuran font
Terakhir diperbarui: 2023-03-27 11:31:14

Overview

When using a TKE or TKE Serverless cluster, you may need to resolve the custom internal domain names in the following scenarios:
You build an external centralized storage service, and want to send the monitoring or log collection data in the cluster to the external storage service through a fixed internal domain name.
During the containerization of traditional services, the code of some services is configured to call other internal services through a fixed domain name, and the configuration cannot be modified, that is, the Service name of Kubernetes cannot be used for calling.

Solutions

This document describes the following three solutions for using custom domain name resolution in a cluster:
Solution
Benefits
This solution is simple and intuitive. You can add arbitrary resolution records.
You do not need to know the IP address of a resolution record in advance, but the IP address mapped by the resolution record must be deployed in the cluster.
You can manage a large number of resolution records. As all records are managed in the external DNS, you do not need to modify the CoreDNS configuration when adding or deleting records.
Note
In the first two solutions, you need to modify the CoreDNS configuration file each time you add a resolution record. The modification takes effect without restart. Select a solution based on your actual needs.

Examples

Solution 1: Using the CoreDNS hosts plugin to configure arbitrary domain name resolution

1. Run the following command to modify the configmap of CoreDNS, as shown below:
kubectl edit configmap coredns -n kube-system
2. Modify the hosts configuration by adding the relevant domain names, as shown below:
hosts {
     192.168.1.6     harbor.example.com
     192.168.1.8     es.example.com
     fallthrough
}
Description
Map harbor.example.com to 192.168.1.6 and es.example.com to 192.168.1.8.
The complete configurations are as follows:
apiVersion: v1
data:
      Corefile: |2-
        .:53 {
            errors
            health
            kubernetes cluster.local. in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            hosts {
                192.168.1.6     harbor.example.com
                192.168.1.8     es.example.com
                fallthrough
            }
            prometheus :9153
            forward . /etc/resolv.conf
            cache 30
            reload
            loadbalance
        }
kind: ConfigMap
metadata:
      labels:
        addonmanager.kubernetes.io/mode: EnsureExists
      name: coredns
      namespace: kube-system

Solution 2: Using the CoreDNS rewrite plugin to map a domain name to a service in the cluster

If you need to deploy a service with a custom domain name in a cluster, you can use the Rewrite plugin of CoreDNS to resolve the specified domain name to the ClusterIP of a Service.
1. Run the following command to modify the configmap of CoreDNS, as shown below:
kubectl edit configmap coredns -n kube-system
2. Run the following command to add the rewrite configuration, as shown below:
rewrite name es.example.com es.logging.svc.cluster.local
Description
Map the es.example.com domain name to the es service deployed in the logging namespace. Separate multiple domain names with carriage returns.
The complete configurations are as follows:
apiVersion: v1
data:
      Corefile: |2-
        .:53 {
            errors
            health
            kubernetes cluster.local. in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            rewrite name es.example.com es.logging.svc.cluster.local
            prometheus :9153
            forward . /etc/resolv.conf
            cache 30
            reload
            loadbalance
        }
kind: ConfigMap
metadata:
      labels:
        addonmanager.kubernetes.io/mode: EnsureExists
      name: coredns
      namespace: kube-system

Solution 3: Using the CoreDNS forward plugin to set the external DNS as the upstream DNS

1. Check the forward configuration. The default configuration of forward is as follows, which means that the domain name that is not in the cluster is resolved by the nameserver configured in the /etc/resolv.conf file of the node where CoreDNS is located.
forward . /etc/resolv.conf
2. Configure forward by replacing /etc/resolv.conf explicitly with the IP address of the external DNS server, as shown below:
forward . 10.10.10.10
The complete configurations are as follows:
apiVersion: v1
data:
   Corefile: |2-
     .:53 {
         errors
         health
         kubernetes cluster.local. in-addr.arpa ip6.arpa {
             pods insecure
             upstream
             fallthrough in-addr.arpa ip6.arpa
         }
         prometheus :9153
         forward . 10.10.10.10
         cache 30
         reload
         loadbalance
     }
kind: ConfigMap
metadata:
   labels:
     addonmanager.kubernetes.io/mode: EnsureExists
   name: coredns
   namespace: kube-system
3. Configure the resolution records of the custom domain names to the external DNS. We recommend that you set the nameserver in /etc/resolv.conf on the node as the upstream of the external DNS. If it is not set as the upstream of the external DNS, some services may not work properly because the services rely on internal DNS resolution of Tencent Cloud. This document takes BIND 9 as an example to modify the configuration file and write the upstream DNS address into forwarders, as shown below:
Note
If the external DNS Server and the request source are not in the same Region, some Tencent domain names that do not support cross-region access may become invalid.
options {
     forwarders {
             183.60.83.19;
             183.60.82.98;
     };
     ...

Learn More

CoreDNS hosts plugin
CoreDNS rewrite plugin
CoreDNS forward plugin
Topik sebelumnya: Using NodeLocal DNS Cache in a TKE ClusterTopik selanjutnya: Quick Start

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan