NginxIngress 애드온 설치
1. TKE 콘솔에 로그인하고 왼쪽 사이드바에서 클러스터를 클릭합니다. 2. ‘클러스터 관리’ 페이지에서 대상 클러스터의 ID를 클릭하여 클러스터 세부 정보 페이지로 이동합니다.
3. 왼쪽 사이드바에서 애드온 관리를 클릭하여 ‘애드온 목록’ 페이지로 이동합니다.
4. ‘애드온 목록’ 페이지에서 생성을 선택합니다. ‘애드온 생성’ 페이지에서 NginxIngress를 선택합니다.
5. 완료를 클릭합니다. 서비스 및 라우팅 > NginxIngress에서 애드온 세부 정보를 볼 수 있습니다.
참고 사항
Tencent Cloud CLB(Cloud Load Balancer) 인스턴스는 2023년 03월 06일에 아키텍처 업그레이드를 완료했습니다. 업그레이드 이후부터는 공중망 CLB는 도메인 이름 형식으로 서비스를 제공합니다. VIP는 서비스 요청에 따라 동적으로 변경되며 콘솔에 더 이상 VIP 주소가 표시되지 않습니다. 도메인 이름 기반 공중망 CLB 출시를 참고하십시오. 신규 Tencent Cloud 사용자는 기본적으로 업그레이드된 도메인 이름 기반 CLB를 사용합니다.
기존 사용자는 기존 CLB를 계속 사용할 수 있으며, 업그레이드에 영향을 받지 않습니다. CLB 서비스를 업그레이드하려면 Tencent Cloud CLB 및 TKE 제품을 동시에 업그레이드해야 하며, 그렇지 않으면 TKE에서 모든 공중망 유형의 Service/Ingress 동기화에 영향을 받을 수 있습니다. CLB 업그레이드 작업의 자세한 내용은 도메인 이름 기반 CLB 업그레이드 가이드를 참고하십시오. TKE Service/Ingress 애드온 버전 업그레이드는 Submit Ticket을 통해 문의하십시오. 설치 방법
다음 설치 방법을 사용하여 비즈니스 시나리오의 요구 사항에 따라 TKE에 Nginx-ingress를 설치할 수 있습니다.
DaemonSet을 사용하여 지정된 노드 풀에 Nginx-ingress 배포(권장)
Nginx는 주요 트래픽 ingress 게이트웨이이므로 다른 비즈니스와 동일한 노드가 아닌 지정된 노드 풀에 Nginx-ingress를 배포하는 것이 좋습니다. 배포 아키텍처는 다음과 같습니다.
설치 단계
설명
이 설치 방법을 사용하면 노드 풀의 전체 확장 기능을 사용할 수 있으며 이후에 노드 풀의 노드 수를 조정하여 Nginx 복제본을 간단히 제거 및 추가할 수 있습니다.
1. Nginx-ingress 배포를 위한 노드 풀을 준비하고 다른 Pod가 노드 풀에 스케쥴링되지 않도록 taint를 설정합니다. 배포 노드 풀에 대한 자세한 내용은 노드 풀 개요를 참고하십시오. 3. 클러스터 정보 페이지에서 서비스 및 라우팅 > NginxIngress를 선택하고 Nginx Ingress 인스턴스 추가를 클릭합니다(클러스터는 여러 Nginx 인스턴스를 가질 수 있음).
4. ‘NginxIngress 생성’ 팝업 창에서 다음과 같이 배포 모드에 대해 배포할 DaemonSet으로 노드 풀 지정을 선택하고 필요에 따라 다른 매개변수를 설정합니다.
노드 풀: 노드 풀을 구성합니다.
Nginx 구성: Requst를 노드 풀의 모델 구성보다 낮은 값으로 설정해야 합니다(노드에 리소스가 예약되어 있음). Limit은 선택 사항입니다.
이미지 버전:
|
<=1.18 | 1.1.0, 1.2.0 | v0.41.0, v0.49.3 |
| 1.0.0 | v0.41.0 |
1.20 | 1.1.0, 1.2.0 | v1.1.3 |
| 1.0.0 | v0.41.0 |
>=1.22 | 1.1.0, 1.2.0 | v1.1.3 |
설명
1. 애드온 EIP 사용 설명: Nginx Ingress 애드온 1.0.0 및 1.1.0 버전은 Tencent Cloud EIP 서비스에 의존합니다. 그러나 v1.2.0 버전부터는 애드온이 더 이상 EIP에 의존하지 않습니다. 따라서 EIP 사용을 제한하려면 Nginx Ingress 애드온을 업그레이드하는 것이 좋습니다. 애드온의 업그레이드는 기존의 Nginx Ingress 인스턴스에 영향을 주지 않으며, 비즈니스 액세스나 데이터 보안에도 영향을 주지 않습니다.
2. 업그레이드 설명: Nginx 인스턴스 버전에 대한 자세한 내용은 GitHub을 참고하십시오. 클러스터를 업그레이드하는 방법은 클러스터 업그레이드를 참고하십시오. Nginx Ingress 애드온을 업그레이드하는 방법은 애드온 업그레이드를 참고하십시오. 5. 확인을 클릭하면 설치가 완료됩니다.
Deployment + HPA 모드 사용 및 배포를 위한 일정 규칙 지정
Deployment + HPA 모드를 사용하여 Nginx-ingress를 배포하는 경우 비즈니스 요구 사항에 따라 분산 방식으로 Nginx 인스턴스 및 비즈니스 Pod를 배포하도록 taint 및 허용 오차를 구성할 수 있습니다. HPA를 사용하면 CPU / 메모리 사용률과 같은 메트릭을 기반으로 Nginx 인스턴스에 대한 Auto Scaling을 구성할 수 있습니다. 배포 아키텍처는 다음과 같습니다.
설치 단계
1. Nginx-ingress 배포를 위한 노드 풀을 준비하고 다른 Pod가 노드 풀에 스케쥴링되지 않도록 taint를 설정합니다. 배포 노드 풀에 대한 자세한 내용은 노드 풀 개요를 참고하십시오. 3. 클러스터 정보 페이지에서 서비스 및 라우팅 > NginxIngress를 선택하고 Nginx Ingress 인스턴스 추가를 클릭합니다(클러스터는 여러 Nginx 인스턴스를 가질 수 있음).
4. ‘NginxIngress 생성’ 팝업 창에서 배포 모드에 사용자 지정 Deployment+HPA를 선택하고, 다음과 같이 필요에 따라 다른 매개변수를 설정합니다.
Nginx 구성: Requst를 노드 풀의 모델 구성보다 낮은 값으로 설정해야 합니다(노드에 리소스가 예약되어 있음). Limit은 선택 사항입니다.
노드 스케쥴링 정책: 필요에 따라 정책을 지정합니다.
이미지 버전:
v1.20 이하의 Kubernetes 클러스터의 경우 Nginx Ingress 애드온 버전은 1.0.0이며, Nginx 인스턴스 이미지 버전은 v41.0만 선택할 수 있습니다.
v1.20 이하의 Kubernetes 클러스터의 경우 Nginx Ingress 애드온 버전은 1.1.0이며, Nginx 인스턴스 이미지 버전은 v41.0 또는 v49.3만 선택할 수 있습니다.
v1.22 이상의 Kubernetes 클러스터의 경우 Nginx Ingress 애드온 버전은 1.1.0이며, Nginx 인스턴스 이미지 버전은 v1.1.3만 선택할 수 있습니다.
설명
Nginx 인스턴스 버전에 대한 자세한 내용은 GitHub을 참고하십시오. 클러스터를 업그레이드하는 방법은 클러스터 업그레이드를 참고하십시오. Nginx Ingress 애드온을 업그레이드하는 방법은 애드온 업그레이드를 참고하십시오. 5. 확인을 클릭하면 설치가 완료됩니다.
Nginx 프런트엔드를 LB에 연결하여 배포
클러스터에 Nginx만 배포된 경우, 외부 트래픽을 수신할 수 없으므로 Nginx 프런트엔드 LB도 구성해야 합니다. TKE는 현재 제품과 같은 설치 기능을 제공하며 비즈니스 요구 사항에 따라 다양한 배포 모드를 선택할 수 있습니다.
VPC-CNI 모드의 클러스터를 Nginx Serivce에 직접 연결(권장)
클러스터가 VPC-CNI 모드인 경우 CLB를 통해 Nginx Serivce에 직접 연결하는 것이 좋습니다. 다음 이미지는 노드 풀 배포 부하의 예시입니다.
CLB의 수동 유지 보수 없이 고성능을 제공하는 이 솔루션은 최적의 솔루션입니다. VPC-CNI를 활성화하려면 클러스터가 필요합니다. 이 솔루션은 VPC-CNI 네트워크 플러그인 또는 VPC-CNI가 활성화된 Global Router 네트워크 플러그인을 구성한 클러스터에 권장됩니다(두 모드 모두 활성화됨).
Globalrouter 모드의 클러스터에서 LoadBalancer 모드의 일반적인 Service 사용
클러스터가 VPC-CNI 모드 네트워크를 지원하지 않는 경우 트래픽 액세스를 위해 LoadBalancer 모드에서 일반 Service를 사용할 수도 있습니다. 현재 TKE에서 LoadBalancer 모드의 Service는 기본적으로 NodePort를 기반으로 구현됩니다. CLB는 각 노드의 NodePort에 바인딩하여 RS로 사용하고 트래픽을 NodePort로 포워딩한 다음 노드에서 iptables 또는 ipvs를 통해 Service의 백엔드 Pod로 요청을 라우팅합니다. 이 방식은 가장 단순하지만 트래픽이 NodePort를 통과하므로 포워딩을 위한 레이어가 하나 더 존재하며 다음과 같은 문제가 존재할 수 있습니다.
포워딩 경로는 상대적으로 깁니다. NodePort에 도달한 후 트래픽은 k8s 내의 CLB를 통과한 다음 iptables 또는 ipvs를 통해 Nginx로 포워딩됩니다. 이는 네트워크 시간 소비를 증가시킵니다.
NodePort를 통과하면 반드시 SNAT가 발생합니다. 트래픽이 너무 집중되면 포트 고갈 또는 conntrack 삽입 충돌이 쉽게 발생하여 패킷 손실 및 일부 트래픽 예외가 발생할 수 있습니다.
각 노드의 NodePort도 CLB 역할을 합니다. CLB가 많은 노드의 NodePort와 바인딩되면 CLB 상태가 각 노드에 분산되어 글로벌 부하 불균형이 쉽게 발생할 수 있습니다.
CLB는 NodePort에서 상태 프로브를 수행하고 프로브 패킷은 궁극적으로 nginx ingress의 Pod로 포워딩됩니다. CLB가 너무 많은 노드와 연결되어 있고 Nginx-ingress의 Pod 수가 적으면 프로브 패킷이 Nginx-ingress에 엄청난 압력을 가하게 됩니다.
HostNetwork + LB 모드 사용
콘솔은 현재 이 모드 설정을 지원하지 않습니다. Nginx 워크로드의 Yaml 파일을 수동으로 수정하여 네트워크 모드를 HostNetwork로 설정하고 CLB 인스턴스를 수동으로 생성하여 Nginx에 의해 노출된 노드 포트를 바인딩할 수 있습니다.
hostNetwork를 사용하는 경우 포트 수신 충돌을 방지하기 위해 Nginx-ingress Pod를 동일한 노드로 스케쥴링할 수 없습니다.
TKE에서 Nginx-ingress 설치를 위한 기본 매개변수
Nginx-ingress 매개변수 설정
Nginx-ingress 애드온의 세부 정보 페이지에서 Nginx 구성 tab에서 YAML을 편집할 Nginx-ingress 인스턴스를 선택할 수 있습니다.
주의사항
기본적으로 Nginx는 매개변수 구성 후 다시 시작하지 않으며 매개변수가 적용되는 데 약간의 시간이 걸립니다.
1. TKE 콘솔에 로그인하고 왼쪽 사이드바에서 클러스터를 클릭합니다. 2. ‘클러스터 관리’ 페이지에서 대상 클러스터의 ID를 클릭하여 클러스터 세부 정보 페이지로 이동합니다.
3. 왼쪽 사이드바에서 애드온 관리를 클릭하여 ‘애드온 목록’ 페이지로 이동합니다.
4. 대상 애드온의 오른쪽에 있는 Nginx 구성 업데이트를 클릭하여 ‘Nginx 구성’ 페이지로 들어갑니다.
5. 대상 Nginx Ingress 인스턴스를 선택하고 YAML 편집을 클릭합니다.
6. ‘ConfigMap 업데이트’ 페이지에서 YAML 파일을 편집하고 완료를 클릭합니다.
매개변수 구성 예시 코드
apiVersion: v1
kind: ConfigMap
metadata:
name: alpha-ingress-nginx-controller
namespace: kube-system
data:
access-log-path: /var/log/nginx/nginx_access.log
error-log-path: /var/log/nginx/nginx_error.log
log-format-upstream: $remote_addr - $remote_user [$time_iso8601] $msec "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] [$proxy_alternative_upstream_name] [$upstream_addr] [$upstream_response_length] [$upstream_response_time] [$upstream_status] $req_id
keep-alive-requests: "10000"
max-worker-connections: "65536"
upstream-keepalive-connections: "200"
주의사항
access-log-path , error-log-path 및 log-format-upstream을 수정하지 마십시오. 그렇지 않으면 CLS 로그 수집이 영향을 받습니다.
비즈니스에 대해 다른 매개변수를 구성하려면 공식 문서를 참고하십시오.