고가용성의 구성 컨트롤러 구성

이 페이지에서는 가용성이 높은 서비스를 운영하거나 여러 Google Cloud 리전에서 리소스를 관리할 때 구성 컨트롤러를 가장 잘 사용하는 방법을 설명합니다.

구성 컨트롤러가 단일 리전에서 실행되므로 가용성 영역 장애를 허용할 수 있지만 전체 리전이 실패하면 구성 컨트롤러를 사용할 수 없게 됩니다. 리전 장애에는 두 가지 대처 전략이 있으며, 리전이 실패할 때 무엇을 수행할지에 따라 옵션을 선택할 수 있습니다.

장애 시나리오 이해

구성 컨트롤러에는 리전별 GKE 클러스터가 사용됩니다. 리전별 클러스터가 리전에서 단일 영역 장애를 허용할 수 있지만 해당 리전에서 여러 영역이 실패하면 클러스터를 사용할 수 없게 됩니다.

구성 컨트롤러 인스턴스가 실패하면 기존 Google Cloud 리소스가 현재 상태로 유지됩니다. 하지만 애플리케이션이 여전히 실행 중인 경우에도 구성 컨트롤러를 사용할 수 없으면 해당 구성을 변경할 수 없습니다. 이는 동일한 리전의 리소스와 사용할 수 없는 리전의 구성 컨트롤러에서 관리하는 다른 리전의 리소스에 적용됩니다.

동일한 리전에서 리소스를 재구성할 수 없으므로 리전 장애가 구성 컨트롤러 리전에서 기존 Google Cloud 리소스에 영향을 주는 경우, 해당 리소스를 복구할 수 없습니다.

다른 리전의 리소스를 다시 구성할 수도 없으므로 현재 한 리전에서 장애가 발생하면 다른 리전에서 변경할 수 없습니다.

다른 장애 시나리오도 가능합니다. 예를 들어 외부 Git 제공업체에서 가져오도록 구성 동기화를 구성할 경우 해당 Git 제공업체의 장애 모드를 고려해야 합니다. 변경사항을 Git 제공업체로 푸시할 수 없으므로 구성을 변경하지 못할 수 있습니다. 또는 구성 동기화가 Git에서 읽을 수 없으면 Git 변경사항이 클러스터에 적용되지 않으므로 구성 컨트롤러가 적용되지 않습니다. 하지만 리전 장애는 가장 중요한 장애 시나리오인 경우가 많습니다. 다른 장애 시나리오는 일반적으로 구성 컨트롤러 장애와 상관 관계가 없기 때문입니다.

리전 가용성에 단일 클러스터 사용

많은 시나리오에서 한 리전이 실패하면 재구성을 수행하지 않습니다. 이 경우 리전 장애로 인해 구성 제어 영역을 사용할 수 없게 될 수 있습니다.

예를 들어 단일 리전에서만 작동하는 경우 해당 리전이 실패하면 수행할 수 있는 유용한 재구성이 없을 수 있습니다. 마찬가지로 단일 장애점 데이터베이스가 단일 리전에 있으면 해당 리전이 복구될 때까지 복구되지 못할 수 있습니다. 절대적인 최고 가용성이 필요하지 않은 애플리케이션에서는 비용이나 복잡성이 적절하게 절충될 수 있습니다.

동일한 리전에서 구성 컨트롤러 인스턴스를 찾으면 기본 리전을 사용할 수 있는 한 구성 컨트롤러를 사용할 수 있습니다. 다른 리전에서 구성 컨트롤러 인스턴스를 찾는 것도 좋은 선택일 수 있습니다. 이제 두 리전의 잠재적 장애를 생각해야 하지만 구성 제어 영역의 상관관계가 있는 장애와 기본 리전의 장애를 방지할 수 있습니다.

또는 멀티 리전 중복 구성이 있으면 시스템이 자동으로 실패한 리전에서 벗어날 수 있습니다. 또한 리전이 실패하면 재구성을 수행하지 않지 않는 것이 좋습니다. 이 경우 단일 구성 컨트롤러 인스턴스를 선택할 수 있습니다.

두 번째 구성 컨트롤러 인스턴스로 수동 장애 조치

리전이 실패하면 오류 해결을 위해 일부 재구성 작업을 수행해야 수 있습니다. 또한 구성 컨트롤러 인스턴스가 실패한 리전에 있더라도 다른 리전에서 리소스를 계속 구성해야 할 수 있습니다. 이 경우에는 두 번째 리전에서 두 번째 구성 컨트롤러 인스턴스를 사용하는 것이 좋습니다.

권장하지는 않지만 두 구성 컨트롤러 인스턴스를 동일한 구성으로 실행할 수 있습니다. 둘 다 동일한 Git 저장소에서 읽고 Google Cloud에 동일한 변경사항을 적용해야 합니다. 그러나 다양한 특이 사례로 인해 이 구성의 안정성이 저하됩니다. 두 구성 컨트롤러 인스턴스는 약간 다른 시점에 Git 저장소를 관찰합니다. Google Cloud 구성의 약간 다른 버전을 적용하려고 할 수 있습니다. Google Cloud에 여러 활성 작성자가 있으면 할당량이나 비율 제한이 발생할 가능성이 높습니다. 소수의 구성 컨트롤러 리소스도 멱등성을 갖지 않으므로 이 섹션의 나머지 부분에서 설명하는 것처럼 더욱 주의해야 합니다. 따라서 구성 컨트롤러 클러스터 두 개 모두 적극적으로 조정하지 않는 것이 좋습니다.

대신 구성 컨트롤러를 실행하는 리전ㅇ이 실패하면 두 번째 리전에서 다른 구성 컨트롤러를 실행하는 것이 좋습니다. 새 구성 컨트롤러 인스턴스를 첫 번째 인스턴스와 동일하게 구성해야 합니다. 그러면 동일한 Git 저장소에서 읽습니다. 이 시나리오에서는 구성 컨트롤러 인스턴스를 불러오고 구성하는 스크립트를 미리 준비하는 것이 유용할 수 있습니다. 새 구성 컨트롤러 인스턴스를 만들면 구성 동기화는 Git에서 원하는 상태를 읽고 Kubernetes에 적용합니다. 구성 커넥터는 원하는 상태를 Google Cloud에 동기화합니다.

여기에서는 두 가지 사항에 주의해야 합니다.

  • 첫 번째 구성 컨트롤러 클러스터가 계속 실행 중이거나 첫 번째 리전이 복구될 때 실행을 시작하면 Google Cloud에 이전 상태를 적용하려고 할 수 있습니다. 두 번째 구성 컨트롤러 클러스터를 시작하기 전에 첫 번째 리전에서 구성 컨트롤러 클러스터를 중지할 수 있으면 이러한 잠재적인 충돌을 방지할 수 있습니다.

  • 일부 구성 커넥터 리소스는 Git에서 원활하게 다시 적용될 수 없습니다. 특별한 주의가 필요한 리소스 목록은 획득 관련 제한사항이 있는 리소스를 참조하세요. 특히 Folder 리소스를 주의하고 IAMServiceAccountKey 리소스를 피하는 것이 좋습니다(예: 대신 GKE 워크로드 아이덴티티 사용).

리전당 구성 컨트롤러 인스턴스 1개

한 리전의 구성 컨트롤러 인스턴스가 다른 리전에 영향을 주지 않도록 하려면 리전별로 구성 컨트롤러 인스턴스를 실행하는 것이 좋습니다. 여기서 각 구성 컨트롤러 인스턴스는 해당 리전의 리소스를 관리합니다.

이 구성은 작동 가능하지만 다음 이유에 따라 권장되는 옵션 중 하나가 아닙니다.

  • Cloud DNS와 같이 일부 리소스가 여러 리전에 걸쳐 있으므로 이 전략의 효과가 제한됩니다.

  • 일반적으로 동일한 리전에 구성 컨트롤러 클러스터가 있으면 상관 관계 장애 문제가 발생합니다. 즉, 리전 장애가 해당 리전의 구성 컨트롤러에 영향을 미치는 경우 리소스를 정확하게 다시 구성하려고 합니다.

  • 구성 커넥터 리소스를 리전별로 분할해야 합니다.

  • 현재 일부 리전에서는 구성 컨트롤러를 사용할 수 없습니다.

Google Cloud 리소스 직접 구성

예외적인 경우 Git 또는 구성 커넥터를 거치지 않고 기본 Google Cloud 리소스를 직접 변경할 수 있습니다. 구성 컨트롤러는 모든 '드리프트'를 해결하려고 하므로 구성 컨트롤러 인스턴스가 계속 실행 중인 경우 구성 컨트롤러는 수동으로 변경한 모든 내용을 '드리프트'로 간주하고 되돌리려고 합니다.

하지만 Config Controller 인스턴스를 중지하거나 리전이 오프라인 상태인 경우 유용한 임시방편이 될 수 있습니다.

구성 컨트롤러 인스턴스가 복구되면 구성 커넥터에서 수동 변경사항을 되돌리려고 합니다. 이 상황을 방지하려면 수동 변경사항을 Git에서 변경하면 됩니다.