콘텐츠로 이동






ETCD구성정보

back

소개

  1. kubernetes의 분산 저장소인 ETCD에 대해 설명하고자 합니다. ETCD는 메모리에 들어갈 수 있는 소량의 데이터를 보관하도록 설계된 저장소로 클러스터환경에서 사용합니다.
  2. ETCD는 'ɛtsiːdiː' 발음 한다고 합니다.
  3. 기본적으로 2G의 용량이 필요하며, 최대 8G까지 사용가능하고 클러스터 멤버 구성은 이론상 제한은 없으나, Google을 참조하면 최대 7대까지 허용하되 5대 노드 구성을 권장한다고 합니다.
  4. 쿼럼 과반이 필요하므로 짝수 클러스터는 장애 허용 측면에서 비효율적이기 때문에 홀수를 권장합니다.
  5. etcd는 Kubernetes 클러스터 상태를 저장하는 분산 Key-Value 저장소이며, 일반적으로 소량의 메타데이터를 빠르고 안정적으로 저장하도록 설계되었다. 기본 storage limit은 2 GiB이고, 8 GiB는 권장 상한선으로 본다. 클러스터는 이론상 더 크게 구성할 수 있지만, 일반적으로 7개 이하를 권장하며 5개 구성은 널리 알려진 권장 예시다.

운영

  1. ETCD의 Disk I/O가 증가하는 경우 disk latency 증가 -> heartbeat 지연/commit 지연 -> leader change 가능성 증가로 인해 Leader에서 제외될 수 있습니다. (Disk fsync의 업데이트 시간이 heartBeat Interval보다 커지면 발생할 수 있는 Case)
  2. HeartBeat 패킷의 주기는 100ms이며, Leader전환하기 전 HeartBeat의 유예기간인 election timeout인 1000ms(1초) 이후에도 응답이 없으면 leader가 변경되기 때문에 network의 지연이 빈번하게 발생할 경우 적절한 튜닝이 필요합니다.
  3. ETCD 운영시 수행되는 작업들은
    1. etcd 데이터 백업방법
    2. etcd member 제외방법 을 참고하세요

튜닝

  1. heartbeat / election
    1. heartbeat interval : 멤버간 평균 왕복시간의 최대값 근처로 조정. (예를 들어 ping을 통해 응답시간을 체크)
    2. election timeout : heartbeat interval을 기준으로 최소 10배 설정 추천. 다만 최대값을 50000ms(50초)이며, 상한값 적용은 country region을 넘어서는 경우에만 사용하고 5000ms(5초)을 넘지 않는 값이 안정적인 운영
  2. Compactionn
    1. ETCD의 용량을 관리하지 않을 경우 성능저하, 용량 부족으로 인해 maintenance모드로 변경하기 때문에 backend 공간이 커지면 성능 저하와 quota 초과 위험이 증가합니다. 때문에 주기적인 Compactionn 수행이 필요합니다.
    2. etcdctl compact 수행은 수동으로 수행하거나 자동으로 압축할 수 있는 방법이 있습니다.
    3. 자동으로 압축을 수행하는 경우 Minor버전에 따라 작동하는 로직이 다르지만, auto-compaction이 설정되어 있는 경우 시간단위로 수행합니다.
      1. 수동으로 Compactionn 수행 설정 (특정치에 대해서 압축작업도 가능합니다) 
        $> cd /usr/local/bin
$> ./etcdctl.sh compact 3
      2. 자동으로 Compaction 수행 
        $> vi /etc/kubernetes/manifests/etcd.yaml
...
apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
      - etcd
      - --auto-compaction-retention=8
...
  3. snapshot
    1. snapshot-count는 WAL에 누적된 proposal 수가 어느 정도 쌓이면 snapshot을 생성할지 결정하는 값입니다. 해당 설정값에 도달하게 되면 스냅샷 데이터를 디스크에 저장한 후 count 이후에 저장된 값을 삭제합니다. (3.4버전 부터는 기본값이 10,000 -> 100,000으로 변경되었습니다)
    2. 성능이 느린 멤버에서 데이터 요청시 leader는 snapshot 데이터를 전송하여 해당 snapshot데이터를 강제로 overwrite하여 데이터를 참조할 수 있습니다
    3. 100,000이상 보관하게 되면 GC가 느려질 수 있으며, 이로인해 즉각적인 메모리 회수가 불가능하기 때문에 할당도 느려집니다. 이로인해 클러스터 가용성과 더불어 쓰기 성능이 저하되는 문제를 가지고 있습니다.
    4. snapshot-count 설정값 
       $> vi /etc/kubernetes/manifests/etcd.yaml
 ...
 apiVersion: v1
 kind: Pod
 ...
 spec:
   containers:
     - command:
       - etcd
       - --snapshot-count=10000
 ...
  4. quota-backend-bytes
    1. etcd의 데이터 공간은 quota-backend-bytes에 설정된 용량을 참고로 사용하며 기본값은 2Gi로 할당되어 있습니다.
    2. 용량변경이 필요한 경우 manifest에 정의하면 해당 POD가 재기동하면서 용량변경 작업이 이루어 집니다.

      다중 master노드에서 용량 변경시 etcd POD 재기동이 수행되기 때문에 노드별로 1~2분 간격으로 1대씩 순차 작업이 필요합니다. (1~2분 간격은 절대적인 수치는 아니고 경험상 확인된 수치)

    3. 설정 변경 방법 
      $> vi /etc/kubernetes/manifests/etcd.yaml
...
apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
      - etcd
      - --quota-backend-bytes=8589934592
...

Reference




작성일: 2026년 6월 18일 ,  마지막 업데이트: 2026년 8월 20일