릴리스 노트
제품 릴리스 기록
카테고리 | 항목 | 유형 | 영향 | 참조 |
클러스터 | 클러스터를 생성하기 전에 애플리케이션 시나리오에 맞게 노드 네트워크 및 컨테이너 네트워크를 계획하여 비즈니스 확장이 제한을 받지 않도록 할 수 있습니다. | 네트워크 계획 | 소규모 서브넷 또는 컨테이너 IP 범위가 있는 경우 클러스터는 애플리케이션에 실제로 필요한 것보다 적은 수의 노드를 지원할 수 있습니다. | |
| 클러스터를 생성하기 전에 Direct Connect, Peering Connection, 컨테이너 IP 범위 및 서브넷 IP 범위 계획을 검토하여 IP 범위 충돌 및 애플리케이션에 대한 영향을 방지하십시오. | 네트워크 계획 | 간단한 네트워크 시나리오의 경우 충돌을 방지하기 위해 페이지의 지침에 따라 클러스터 관련 IP 범위를 구성하십시오. Peering Connection, Direct Connect 및 VPN과 같은 복잡한 네트워킹 시나리오의 경우 부적절한 네트워크 계획은 애플리케이션 내의 정상적인 통신에 영향을 미칠 수 있습니다. | - |
| 클러스터를 생성하면 새 보안 그룹이 자동으로 클러스터에 바인딩됩니다. 애플리케이션의 요구 사항을 충족하도록 사용자 지정 보안 그룹 규칙을 설정할 수도 있습니다. | 배포 | 보안 그룹은 중요한 보안 격리 수단을 제공합니다. 부적절한 보안 정책 구성은 보안 관련 위험, 서비스 연결 문제 및 기타 문제로 이어질 수 있습니다. | |
| 현재 TKE에서 지원하는 런타임 구성 요소인 Containerd와 Docker는 각각 다른 시나리오에 적합합니다. 클러스터를 생성할 때 애플리케이션 시나리오에 따라 적절한 컨테이너 런타임(Container Runtime) 컴포넌트를 선택합니다. | 배포 | 클러스터가 생성되면 런타임 컴포넌트 및 버전에 대한 수정 사항은 노드 풀에 할당되지 않은 새 노드에만 적용됩니다. 기존 노드는 영향을 받지 않습니다. | |
| 기본적으로 Kube-proxy는 iptables를 사용하여 Service와 Pod 사이의 부하를 분산합니다. 클러스터를 생성할 때 트래픽 분산 및 로드 밸런싱을 위해 IPVS를 빠르게 활성화할 수 있습니다. | 배포 | 클러스터를 생성할 때 IPVS를 활성화할 수 있습니다. 전체 클러스터에 적용되며 비활성화할 수 없습니다. | |
| 클러스터를 생성할 때 필요에 따라 독립 클러스터 모드 또는 관리 클러스터 모드를 선택합니다. | 배포 | 관리형 클러스터의 Master 및 Etcd는 사용자 리소스가 아니며 Tencent Cloud의 기술 팀에서 관리하고 유지합니다. Master 및 Etcd의 배포 규모 및 서비스 매개변수는 수정할 수 없습니다. 수정해야 하는 경우 독립 배포 모드를 선택합니다. | |
워크로드 | 워크로드를 생성할 때 애플리케이션의 견고성을 개선하기 위해 CPU 및 메모리 제한을 설정합니다. | 배포 | 하나의 노드에 여러 개의 애플리케이션을 배포할 때 리소스 상한 및 하한이 없는 애플리케이션에서 리소스 유출이 발생하면 리소스 부족으로 인해 동일한 노드의 다른 애플리케이션에서 예외가 발생하고 모니터링 정보 오류를 보고합니다. | |
| 워크로드를 생성할 때 ‘활성 확인’ 및 ‘준비 확인’의 컨테이너 상태 확인을 구성할 수 있습니다. | 신뢰성 | 컨테이너 상태 확인이 구성되지 않은 경우 애플리케이션 예외가 발생하면 Pod가 이를 감지하여 복구를 위해 애플리케이션을 자동으로 다시 시작할 수 없습니다. 이 경우 Pod가 정상인 것처럼 보이지만 Pod의 애플리케이션은 비정상적으로 작동합니다. | |
| 서비스를 생성할 때 필요에 따라 적절한 서비스 액세스 방법을 선택합니다. 현재 인터넷을 통해, 클러스터 내, VPC를 통해, 노드 포트 액세스의 네 가지 액세스 방법이 지원됩니다. | 배포 | 부적절한 액세스 방식은 접근 로직 혼란을 야기하고 서비스 내외에서 리소스를 낭비할 수 있습니다. | |
| 워크로드를 생성할 때 Pod 복제본 수를 1로 설정하지 마십시오. 애플리케이션의 요구 사항에 따라 노드 스케쥴링 정책을 설정하십시오. | 신뢰성 | Pod 복제본 수를 1로 설정하면 노드 예외 또는 Pod 예외가 발생할 때 서비스 예외가 발생합니다. Pod를 성공적으로 스케쥴링할 수 있도록 스케쥴링 규칙을 설정한 후 노드에 컨테이너 스케쥴링에 사용할 수 있는 리소스가 있는지 확인합니다. | |
카테고리 | 항목 | 유형 | 영향 | 참조 |
컨테이너 데이터 지속성 | Pod 데이터 스토리지를 적용하고 필요에 따라 적절한 볼륨 유형을 선택합니다. | 신뢰성 | 예외 발생 후 노드 복구에 실패하면 로컬 디스크의 데이터를 복구할 수 없습니다. 그러나 클라우드 스토리지는 이러한 상황에서 매우 높은 데이터 신뢰성을 제공할 수 있습니다. |
카테고리 | 항목 | 유형 | 영향 | 참조 |
엔지니어링 | CVM, VPC, 서브넷 및 CBS 디스크와 같은 리소스 할당량이 고객 요구를 충족할 수 있는지 확인합니다. | 배포 | 할당량이 부족하면 리소스 생성이 실패합니다. Auto Scaling을 활성화한 경우 Tencent Cloud 서비스에 대한 할당량이 충분한지 확인하십시오. | |
| 클러스터의 노드에서 커널 매개변수, 시스템 구성, 클러스터 핵심 컴포넌트 버전, 보안 그룹 및 LB 매개변수를 수정하지 않는 것이 좋습니다. | 배포 | 이로 인해 노드에 설치된 TKE 클러스터 기능 또는 Kubernetes 컴포넌트가 실패하여 애플리케이션 배포에 노드를 사용할 수 없게 될 수 있습니다. | |
능동적인 OPS | TKE는 Cloud Monitor에서 제공하는 기본 리소스 모니터링과 함께 다차원 모니터링 및 알람 기능을 제공하여 보다 세분화된 메트릭을 제공합니다. 모니터링 및 알람을 구성하면 예외 발생 시 즉각적인 알람을 수신하고 오류를 찾는 데 도움이 됩니다. | 모니터링 | 모니터링 및 알람 기능을 구성하지 않으면 컨테이너 클러스터 성능에 대한 정상적인 기준을 세울 수 없으며, 예외 발생 시 알람이 즉시 수신되지 않습니다. 이 경우 환경을 수동으로 검사해야 합니다. | |
피드백