Elastic Cloud on Kubernetes (ECK)를 운영하는 경우, 이번 릴리즈는 매일 수행하는 작업의 불편함을 줄이는 데 중점을 두고 있습니다.

더 쉬운 조작, 더 쉬운 이해

ECK 3.4는 Kubernetes에서 Elastic Stack을 실행할 때 고려해야 할 사항을 줄이는 데 중점을 둔 릴리즈입니다. 각 주요 변경 사항은 여러 단계를 거치는 작업을 단일의 선언적 답변으로 전환합니다.

• 간소화된 영역 인식. 클러스터를 여러 가용 영역에 확산시켜야 한다는 것을 ECK에 알리는 작업은 이제 NodeSet의 단일 필드로 처리됩니다. 오퍼레이터가 사용자를 대신하여 토폴로지, 스케줄링 및 Elasticsearch 측 인식 구성을 처리합니다. 매니페스트는 실제 연결 방식이 아닌 사용자의 의도를 반영합니다.

• 다른 모든 작업을 수행하는 것과 동일한 방식으로 클러스터를 다시 시작하세요. 이제 롤링 재시작 트리거가 Elasticsearch 리소스에 어노테이션으로 추가됩니다. 선언적이고 GitOps에 적합하며 감사 추적을 남깁니다. 롤아웃을 위해 관련 없는 필드를 강제 편집할 필요가 없습니다.

• mTLS는 오퍼레이터가 자동으로 구성합니다. Kibana와 Elasticsearch 간에 상호 TLS를 수작업으로 연결하려면 양쪽 끝에서 CA, 구성 요소별 클라이언트 인증서, 마운트, 로테이션, 구성을 관리해야 합니다. ECK 3.4는 이 모든 것을 처리합니다. Elasticsearch에서 플래그를 활성화하고 Kibana를 가리키면 나머지는 운영자가 관리합니다.

이번 릴리즈는 ECK의 일상적인 운영을 최대한 간편하게 만들어주는 것을 목표로 합니다. 기억해야 할 필드가 줄어들고 동기화해야 할 추가 작업이 줄어들며 매니페스트를 더 쉽게 이해할 수 있게 되었습니다.

간소화된 영역 인식

NodeSet에서 하나의 필드를 설정하여 가용성 영역 전반에서 Elasticsearch 클러스터의 고가용성을 확보하세요. ECK 3.4는 토폴로지 확산, 포드 스케줄링, Elasticsearch 측 인식 구성을 처리합니다.

이전에는 이 모든 것을 네 개의 개별 객체에 걸쳐 수동으로 연결해야 했습니다. 하위 노드 레이블을 위한 Elasticsearch 리소스의 어노테이션, NodeSet 구성의 인식 속성, 영역을 표시하는 포드 템플릿의 fieldRef 환경 변수, 그리고 일치하는 topologySpreadConstraints 블록과 클러스터를 특정 영역에 고정하는 nodeAffinity 규칙이 필요했습니다. 대략 40줄의 YAML 코드로, 잘못 구성하기 쉬웠습니다.

ECK 3.4에서 동일한 영역 인식 클러스터는 네 줄로 구성됩니다.

특정 영역 세트에 고정하려면 해당 영역에 이름을 지정하세요. 그러면 ECK가 해당 영역에 필요한 Node 선호도 규칙을 추가합니다.

maxSkew 또는 whenUnsatisfiable 을 사용자 정의해야 하는 경우 podTemplate 에서 동일한 topologyKey (으)로 일치하는 토폴로지 확산 제약 조건을 제공하는 것이 여전히 우선합니다. 재정의는 재정의로 유지됩니다.

업그레이드 시 유의사항: 기존 NodeSet에서 zoneAwareness을(를) 활성화하면 StatefulSet 포드 템플릿이 변경됩니다(새로운 토폴로지 확산 제약 조건, ZONE 환경 변수, 노드 선호도, node.attr.zone). 이로 인해 해당 NodeSet에 대해 일회성 롤링 재시작이 트리거됩니다. 따라서 업그레이드 계획을 세울 때 이 점을 고려하세요.

간소화된 영역 관리에 대해 자세히 알아보려면 Elastic 설명서에서 이 페이지를 읽어보세요.

선언적 롤링 재시작

이제 3.4에서는 사양을 변경하지 않고 Elasticsearch 클러스터를 재시작하는 것이 최고급 워크플로우가 되었습니다. 다음과 같이 Elasticsearch 리소스에 대한 두 개의 새로운 어노테이션이 작업을 수행합니다.

• eck.k8s.elastic.co/restart-trigger이 값을 설정하거나 변경(타임스탬프가 일반적인 선택 사항)하여 롤링 재시작을 시작합니다. 값을 변경하면 나중에 다시 재시작이 트리거되지만 어노테이션을 제거하면 트리거되지 않습니다.

• eck.k8s.elastic.co/restart-allocation-delay재시작 중 할당 지연 시간으로 Elasticsearch 노드 종료 API에 전달되는 선택적 지속 시간 스트링(예: "20m")입니다. 이를 통해 포드가 재활용되는 동안 리밸런싱을 보류할 수 있습니다.

ECK는 내부적으로 트리거 값을 포드 어노테이션에 전파하여 StatefulSet 템플릿 해시를 변경하고, 기존의 롤링 업그레이드 경로(노드 종료 API, 조건자, 한 번에 하나의 포드 삭제)를 통해 모든 포드를 피드합니다. 새로 배워야 할 재시작 메커니즘이 없으며, 기존 롤링 업그레이드에서 사용하던 상태 메시지와 통합 가시성도 그대로 유지됩니다.

GitOps 사용자의 경우 이는 Flux/ArgoCD 파이프라인이 하나의 어노테이션을 패치하여 재시작을 요청할 수 있다는 의미입니다(사양 드리프트, 차이점 이탈, 관련 없는 필드에 대한 강제 편집 없음).

관리형 mTLS for Kibana ↔ Elasticsearch

이번 릴리즈에서는 Kibana와 Elasticsearch 간의 상호 TLS 오케스트레이션이 제공됩니다. Elasticsearch CRD는 단일 새 필드( spec.http.tls.client.authentication: true)를 수락하여 클러스터에 HTTP 인터페이스에서 클라이언트 인증서를 요구하도록 지시합니다. ECK는 나머지 작업을 수행합니다. eck.k8s.elastic.co/client-certificate: true(으)로 레이블이 지정된 모든 시크릿에서 트러스트 번들을 구축하고, 이를 Elasticsearch 포드에 마운트하고, xpack.security.http.ssl.client_authentication: required을(를) 설정하고, 오퍼레이터 측 클라이언트 인증서를 발급하여 롤아웃 과정 전반에 걸쳐 클러스터와 지속적으로 통신할 수 있도록 합니다.

따라서 스택(이번 릴리즈에서는 Elasticsearch와 Kibana에만 해당)에 대한 mTLS 활성화 및 구성 작업이 훨씬 더 간단해집니다.

Elasticsearch에서 mTLS 활성화하기:

클라이언트 측에서 Kibana의 연결 컨트롤러는 이제 참조된 Elasticsearch의 client-authentication-required 어노테이션을 탐지하고 Kibana용 클라이언트 인증서를 자동으로 생성합니다. 추가 구성은 필요하지 않습니다. 자체 인증서(cert-manager 또는 내부 PKI)를 사용하려면 이미 프로비저닝한 시크릿을 지정하면 됩니다.

ECK는 인증서를 회전하고, 시크릿을 Kibana 포드에 마운트하고, elasticsearch.ssl.certificate 및 elasticsearch.ssl.key 을(를) 연결합니다. 모든 포드가 롤링될 때까지 mTLS 리소스 정리가 연기되므로 전환하는 동안 연결이 유지됩니다.

Kibana는 3.4에서 이러한 최고 수준의 지원을 받는 최초의 Stack 구성 요소입니다. APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps 및 Enterprise Search에 대한 지원은 조만간 제공될 예정입니다. 그동안 인증 관리자를 사용하여 이러한 구성 요소에 대한 수동 mTLS를 안내하는 새로운 레시피를 참조하세요.

기타 주목할 만한 개선 사항

이번 릴리즈에는 주목할 만한 다른 개선 사항도 포함되어 있습니다. 관련 풀 리퀘스트 목록은 다음과 같습니다.

• FIPS 지원 오퍼레이터(별도 이미지)에 네이티브 Go FIPS 140-3 지원이 추가되었습니다. FIPS 지원 ECK 이미지(docker.elastic.co/eck/eck-operator-fips:3.4.0, UBI 변형 eck-operator-ubi-fips:3.4.0 포함)는 이제 인증된 GOFIPS140=v1.0.0 모듈에 고정되어 런타임에 적용되는 네이티브 Go FIPS 140-3 지원 기능을 제공합니다. 표준 eck-operator 이미지는 변경되지 않았습니다. Elasticsearch 9.4.0 이상 버전의 경우 오퍼레이터는 xpack.security.fips_mode.enabled: true이(가) 설정되면 FIPS를 준수하는 키 저장소 비밀번호를 자동으로 생성하고 마운트합니다(#9263, #9287).

• 주목할 만한 신뢰성 수정 사항:

  • 이제 인증서 체인에서 오래된 CA가 탐지되어 재발급이 트리거됩니다(#9197).

  • 원격 CA 시크릿 생성 실패는 차단되지 않습니다(#9271).

  • 소프트 멀티 테넌시 설정의 경우 NetworkPolicy 네임스페이스 선택자 레이블이 고정됩니다(#9153).

  • 같은 이름의 볼륨이 이미 존재하는 경우(#9199) Elasticsearch 컨트롤러는 기본 PVC를 건너뜁니다.

  • DaemonSet 조정자는 Deployment 조정자와 동일한 방식으로 오래된 캐시를 처리합니다(#9256).

시작하기

이미 ECK를 실행하고 있다면 다음과 같이 Helm을 사용하여 3.4.0으로 업그레이드하세요.

또는 다음과 같이 최신 오퍼레이터 매니페스트를 직접 적용하세요.

ECK를 처음 사용하는 경우 빠른 시작 가이드로 시작하여 몇 분 안에 Kubernetes에서 Elasticsearch 클러스터를 실행할 수 있습니다.

전체 변경 사항 목록은 GitHub에서 ECK 3.4.0 릴리즈 노트를 참조하세요.

지금 바로 Elastic Cloud를 사용하려면 Elastic Cloud 콘솔에 로그인하거나 무료 체험판에 등록하세요.

자주 하는 질문

토폴로지 확산 제약 조건을 작성하지 않고 ECK에서 Elasticsearch 클러스터 영역 인식을 만들려면 어떻게 해야 하나요?

Elasticsearch 리소스에 spec.nodeSets[].zoneAwareness: {}을(를) 설정합니다. ECK는 토폴로지를 도출하고, node.attr.zone을(를) 연결하고, maxSkew=1 토폴로지 확산 제약 조건을 설정하고, 하향 레이블을 자동으로 주입합니다. 특정 가용 영역 세트에 고정하려면 zones: [...]을(를) 제공합니다. 기존 NodeSet에서 이 기능을 활성화하면 일회성 롤링 재시작이 수행됩니다.

Kubernetes에서 Elasticsearch 클러스터의 사양을 수정하지 않고 롤링 재시작을 트리거할 수 있나요?

예. ECK 3.4에서는 Elasticsearch 리소스에 두 가지 어노테이션이 도입되었습니다. eck.k8s.elastic.co/restart-trigger은(는) 롤링 재시작을 시작하기 위해 타임스탬프와 같은 값을 설정하거나 변경하는 어노테이션이고, eck.k8s.elastic.co/restart-allocation-delay은(는) Elasticsearch 노드 종료 API에 전달되는 선택적 지속 시간 스트링입니다. 트리거 어노테이션을 제거해도 새 재시작은 시작되지 않습니다.

Kubernetes에서 Kibana와 Elasticsearch 간에 상호 TLS를 활성화하려면 어떻게 해야 하나요?

ECK 3.4에서는 Elasticsearch CRD에 spec.http.tls.client.authentication: true을(를) 설정하고 Kibana에서 elasticsearchRef을(를) 통해 참조할 수 있습니다. ECK는 Kibana용 클라이언트 인증서를 자동으로 생성하고, eck.k8s.elastic.co/client-certificate: true(으)로 레이블이 지정된 모든 시크릿으로부터 트러스트 번들을 구축하고, xpack.security.http.ssl.client_authentication: required을(를) 구성합니다. mTLS for Kibana ↔ Elasticsearch는 3.4에서 기술 미리 보기로 제공됩니다.

ECK 3.4 mTLS 지원이 Beats 및 Fleet과 같은 모든 Stack 구성 요소를 포함하나요?

아직은 아닙니다. Kibana는 3.4에서 오퍼레이터가 클라이언트 인증서를 자동 생성하는 최고 수준의 mTLS 지원을 제공하는 최초의 Stack 구성 요소입니다. 다음 릴리즈에서는 APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps 및 Enterprise Search에 대한 지원이 제공될 예정입니다. 그 동안 인증 관리자를 사용하여 이러한 구성 요소에 대한 수동 mTLS를 안내하는 새로운 레시피를 참조하세요.

ECK는 FIPS 140-3을 지원하나요?

예, 별도의 오퍼레이터 이미지로 제공됩니다. ECK 3.4는 네이티브 Go FIPS 140-3 지원이 포함된 FIPS 기반 빌드(docker.elastic.co/eck/eck-operator-fips:3.4.0, UBI 변형 포함)를 게시합니다. 표준 eck-operator 이미지는 변경되지 않았습니다. Elasticsearch 9.4.0 이상 버전의 경우xpack.security.fips_mode.enabled: true 이(가) 설정되면 ECK는 FIPS를 준수하는 키 저장소 비밀번호를 자동으로 생성하고 마운트합니다.