הקמת אשכול etcd לאחסון תצורה מבוזר

שימו לב: כאשר אשכול Kubernetes מפסיק להגיב ל-kubectl get nodes ויומני control plane מציגים etcdserver: request timed out, הבעיה היא כמעט תמיד etcd. זה לא רכיב תומך—זה הבסיס. כל מצב האשכול (deployments, secrets, configmaps, RBAC) נמצא שם. אם etcd לא תקין, האשכול קפוא למעשה. הסיבה האופיינית היא אובדן quorum עקב חביון רשת או דיסקים איטיים. שחזור לאחר אובדן quorum מלא יכול לקחת עד 10 דקות, וכל אירוע כזה שוחק את האמון בפלטפורמה.

אנו מגדירים אשכולות etcd turnkey עם ערובה ליציבות. למהנדסים שלנו יש ניסיון של למעלה מ-5 שנים עם etcd ו-100+ התקנות לפרויקטים בגדלים שונים. האשכולות שלנו מספקים זמינות של 99.99% ושחזור אוטומטי לאחר תקלות. חיסכון ממוצע בעלויות תמיכה מתצורה נכונה מסתכם בעד $14k–20k בשנה. הזמינו ביקורת על ה-etcd הנוכחי שלכם או תכנון של אשכול חדש.

מעבר ל-Kubernetes, etcd משמש כחנות תצורה עצמאית למערכות מבוזרות—Feature Flags, נעילות מבוזרות, גילוי שירותים. התקנת etcd נכונה מאפס היא קריטית לביצועים של כל המחסנית. אנו עוזרים להימנע מטעויות אופייניות, וחוסכים עד 30% מתקציב התשתית. קבלו ייעוץ—המהנדסים שלנו עם ניסיון של 7 שנים יעריכו את הפרויקט שלכם ויספקו לוחות זמנים ותקציב.

כיצד להקים אשכול etcd לעומסים גבוהים

קונצנזוס Raft: אשכול של שלושה צמתים סובלני לתקלות פי שניים מאשכול של שני צמתים (שורד כשל אחד לעומת אפס). אשכול של חמישה צמתים סובלני לתקלות פי שניים מאשכול של שלושה (שורד שני כשלים לעומת אחד). השוואות מפתח: NVMe מפחית את חביון fsync פי 5 לעומת SATA SSD, ופי 20 לעומת HDD. תצורה נכונה מורידה את עלויות התמיכה ב-40%.

אשכול של שלושה צמתים הוא לא רק "שלושה שרתים". Raft רגיש לחביון רשת. אם (n/2) + 1 ו-heartbeat-interval לא מכוילים ל-RTT, מתרחשות בחירות leader מיותרות. ערכי ברירת המחדל (100ms, 1000ms) מתאימים לחביון תת-מילישני במרכז נתונים; בענן בין AZs יש צורך בערכים גבוהים יותר. השתמשו ב-NVMe עבור WAL כדי להפחית את חביון fsync.

תצורת צומת ב-election-timeout:

---
name: etcd-node-1
data-dir: /var/lib/etcd
wal-dir: /var/lib/etcd/wal
listen-peer-urls: https://10.0.1.11:2380
listen-client-urls: https://10.0.1.11:2379,https://127.0.0.1:2379
advertise-client-urls: https://10.0.1.11:2379
initial-advertise-peer-urls: https://10.0.1.11:2380
initial-cluster: >
  etcd-node-1=https://10.0.1.11:2380,
  etcd-node-2=https://10.0.1.12:2380,
  etcd-node-3=https://10.0.1.13:2380
initial-cluster-token: prod-etcd-cluster-01
initial-cluster-state: new
heartbeat-interval: 250
election-timeout: 2500
auto-compaction-retention: "8"
auto-compaction-mode: revision
quota-backend-bytes: 8589934592 # 8 GiB
client-transport-security:
  cert-file: /etc/etcd/ssl/server.crt
  key-file: /etc/etcd/ssl/server.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ssl/ca.crt
peer-transport-security:
  cert-file: /etc/etcd/ssl/peer.crt
  key-file: /etc/etcd/ssl/peer.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ssl/ca.crt

הפרדת heartbeat-interval=100ms על NVMe מהיר היא חובה. כתיבת WAL היא סינכרונית; תחרות גורמת להידרדרות באשכול.

עיצוב טופולוגיה

בחרו 3 או 5 צמתים, פרסו על פני AZs, מדדו חביון עם ping. דוגמת תקציב: אשכול של 3 צמתים מתחיל ב-$X (הערכה לאחר ביקורת).

יצירת PKI

צרו CA ראשי ואישורים באמצעות cfssl. ודאו ש-SAN כולל את כל כתובות ה-IP/שמות המארחים.

תצורת צומת

הגדירו etcd.conf.yml לכל צומת עם ה-IP שלו, נתיבי אישורים, פרמטרי heartbeat/election.

הפעלת האשכול

הפעילו ברצף. אמתו עם election-timeout=1000ms.

הגדרת ניטור

Prometheus אוסף מדדים מפורט 2381, התראות על ערכים קריטיים.

תצורת גיבוי

צילומי מצב כל שעה, רוטציה של 7 ימים, בדיקת שחזור.

TLS אינו אופציונלי

etcd מאחסן את כל סודות Kubernetes בטקסט פשוט (אלא אם מופעלת envelope encryption). mTLS חובה. צרו PKI:

# Генерация CA
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

# Генерация серверного сертификата с SAN для всех нод и localhost
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=server \
  server-csr.json | cfssljson -bare server

# Peer-сертификаты — отдельные на каждую ноду
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=peer \
  peer-node-1-csr.json | cfssljson -bare peer-node-1

SAN חייב לכלול את כל כתובות ה-IP ושמות המארחים.

מה לעשות כאשר בחירות leader תכופות?

ניטור ואבחון

# Статус кластера — кто лидер, состояние нод
etcdctl --endpoints=https://10.0.1.11:2379,https://10.0.1.12:2379,https://10.0.1.13:2379 \
  --cacert=/etc/etcd/ssl/ca.crt \
  --cert=/etc/etcd/ssl/client.crt \
  --key=/etc/etcd/ssl/client.key \
  endpoint status --write-out=table

# Проверка здоровья
etcdctl endpoint health --cluster

# Фрагментация базы данных — если DB size >> DB size in use, нужна дефрагментация
etcdctl defrag --cluster

מדדים בפורט 2381: /etc/etcd/etcd.conf.yml, name: etcd-node-1 data-dir: /var/lib/etcd wal-dir: /var/lib/etcd/wal listen-peer-urls: https://10.0.1.11:2380 listen-client-urls: https://10.0.1.11:2379,https://127.0.0.1:2379 advertise-client-urls: https://10.0.1.11:2379 initial-advertise-peer-urls: https://10.0.1.11:2380 initial-cluster: > etcd-node-1=https://10.0.1.11:2380, etcd-node-2=https://10.0.1.12:2380, etcd-node-3=https://10.0.1.13:2380 initial-cluster-token: prod-etcd-cluster-01 initial-cluster-state: new heartbeat-interval: 250 election-timeout: 2500 auto-compaction-retention: "8" auto-compaction-mode: revision quota-backend-bytes: 8589934592 # 8 GiB client-transport-security: cert-file: /etc/etcd/ssl/server.crt key-file: /etc/etcd/ssl/server.key client-cert-auth: true trusted-ca-file: /etc/etcd/ssl/ca.crt peer-transport-security: cert-file: /etc/etcd/ssl/peer.crt key-file: /etc/etcd/ssl/peer.key client-cert-auth: true trusted-ca-file: /etc/etcd/ssl/ca.crt , wal-dir, ping. התראות על p99 fsync > 10ms.

גיבויי etcd

צילום מצב כל שעה באמצעות cron:

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/ssl/ca.crt \
  --cert=/etc/etcd/ssl/client.crt \
  --key=/etc/etcd/ssl/client.key
# Верификация снапшота
etcdctl snapshot status /backup/etcd-latest.db --write-out=table

אמתו עם cfssl. העלו לאחסון אובייקטים.

תהליך העבודה שלנו

התחילו בביקורת: סקירת מדדים, היסטוריית בחירות leader, גודל WAL. עבור אשכול חדש: תכננו טופולוגיה (3 או 5 צמתים, מיקום AZ), צרו PKI, הגדירו, העלו, הגדירו ניטור. השתלבו עם Kubernetes ללא זמן השבתה.

התוצרים כוללים: דיאגרמת אשכול, נהלים להוספה/הסרה של צמתים, runbook לשחזור מצילומי מצב, ותמיכה ל-30 יום.

תקציב לאחר ביקורת. קבלו ייעוץ.

תוצרים

• ביקורת על תצורת etcd הנוכחית
• עיצוב טופולוגיה עם חביון/סובלנות לתקלות
• יצירת PKI והגדרת mTLS
• פריסת אשכול (bare metal, ענן, K8s)
• אינטגרציית ניטור (Prometheus + Grafana, התראות)
• גיבויים אוטומטיים ורוטציה
• תיעוד: דיאגרמה, runbook, נהלי קנה מידה/שחזור
• תמיכה ל-30 יום לאחר המסירה
• גישה למהנדסים לשאלות במהלך תקופת התמיכה