etcd: Цифровой мозг Kubernetes и современных систем

Вечером предлагаю поговорить не о командах, а об идеях. Что общего у Kubernetes, Cloudflare, CoreDNS и десятков других сложных систем? В их основе лежит один и тот же тихий и невероятно надежный компонент — etcd.

Многие админы никогда не работали с ним напрямую, но именно он является цифровой нервной системой для самых критичных частей современной инфраструктуры.

Что такое etcd простыми словами?

Это распределенное хранилище формата «ключ-значение». По сути, это как словарь или телефонная книга, но размазанная по нескольким серверам (кластеру).

Его суперсила — гарантия консистентности. Благодаря алгоритму консенсуса Raft, если вы записали данные в etcd, вы можете быть на 100% уверены, что они сохранены, верны и одинаковы на всех узлах. Кластер etcd может пережить отказ нескольких серверов, не потеряв ни байта.

Почему это так важно для архитектора?
В распределенной системе (как Kubernetes) главная проблема — договориться. Как сотни компонентов (scheduler, kubelet, controllers) должны знать, в каком состоянии находится кластер? Какое состояние является «правильным»?

etcd решает эту проблему, выступая как единый источник правды (Single Source of Truth).

Хранение состояния: В etcd хранится вся конфигурация K8s кластера: какие поды должны быть запущены, какие у них IP, какие секреты используются. Это «желаемое состояние» системы.

Координация и блокировки: Какой контроллер сейчас главный (leader election)? etcd помогает сервисам «договориться» и избежать конфликтов.

Обнаружение сервисов (Service Discovery): Как один сервис находит другой? Он смотрит в etcd, как в адресную книгу.

Что это значит для нас, админов?
Понимание etcd — это ключ к пониманию того, как работает и «думает» Kubernetes.

Бэкап etcd — это бэкап всего состояния вашего кластера. Потеряете etcd — потеряете всё. Это самая важная резервная копия в мире K8s.

Здоровье etcd — это здоровье вашего кластера. Медленный диск под etcd = медленный API и медленная работа всего оркестратора.

С помощью утилиты etcdctl можно напрямую заглянуть «в мозг» кластера (но делать это в prod нужно с большой осторожностью).

Итог: etcd — это не просто база данных. Это фундаментальный паттерн для построения отказоустойчивых распределенных систем. Понимание принципов его работы — прямой шаг от администрирования отдельных машин к проектированию сложных, надежных экосистем.

Отличного вечера!

#Kubernetes #DistributedSystems #etcd #DevOps #Архитектура #SysAdmin

Проект на выходные: Запускаем Windows VM... внутри Kubernetes. Знакомство с KubeVirt

Проблема: Ваша компания перешла на Kubernetes. 90% сервисов — контейнеры. Но у вас остался "старый, добрый" монолит на Windows Server (например, 1С или старый IIS-апп), который нельзя контейнеризировать.

Решение: Не держать "зоопарк" (Kubernetes + Proxmox/VMware). А запустить эту VM внутри Kubernetes.

KubeVirt — это проект CNCF, который позволяет управлять Виртуальными Машинами (VM) так же, как и контейнерами.

Как это работает: Вы пишете YAML-манифест так же, как для Deployment, но с типом VirtualMachineInstance.
YAML

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-windows-vm
spec:
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
        # ...и т.д.

Взгляд архитектора: Это "Единый Оркестратор". У вас ОДИН инструмент (kubectl) и ОДНА "панель управления" (Kubernetes) для всех ваших нагрузок — и современных (контейнеры), и "легаси" (VM). Это упрощает сеть, хранилище и мониторинг.

#linux #kubernetes #kubevirt #devops #virtualization #architect #гайд

Kubernetes (Security): Аудит «привилегированных» Pod’ов и опасных контекстов

Боль: Кластер «зелёный», но в проде внезапно есть Pod’ы с privileged, hostNetwork и контейнеры, которые по факту бегут от root.
Реакция админа: «Они же работают».
Реакция архитектора: «Любая эскалация — это вопрос времени. Я хочу сигнал в моменте.»

Скрипт (Bash + kubectl + jq), выводит только рискованные контейнеры:

#!/usr/bin/env bash
# --- Kubernetes Risky Pods Audit ---
set -euo pipefail

command -v kubectl >/dev/null || { echo "[!!!] Требуется kubectl"; exit 2; }
command -v jq >/dev/null || { echo "[!!!] Требуется jq"; exit 2; }

echo "--- Начинаю аудит Pod'ов с опасными настройками ---"

data=$(kubectl get pods -A -o json)
echo "$data" | jq -r '
  [.items[] as $p
   | ($p.spec.containers + ($p.spec.initContainers // []))[]? as $c
   | {
       ns: $p.metadata.namespace,
       pod: $p.metadata.name,
       cont: $c.name,
       img: $c.image,
       privileged: ($c.securityContext.privileged // false),
       hostNetwork: ($p.spec.hostNetwork // false),
       hostPID: ($p.spec.hostPID // false),
       runAsRoot:
         ((( $c.securityContext.runAsUser
           // $p.spec.securityContext.runAsUser // null) == 0)
          or ( ($c.securityContext.runAsNonRoot
                // $p.spec.securityContext.runAsNonRoot // false) == false)),
       capAdd: ($c.securityContext.capabilities.add // [])
     }
  ]
  | map(select(.privileged or .hostNetwork or .hostPID or .runAsRoot
               or (.capAdd | index("SYS_ADMIN") or index("NET_ADMIN"))))
  | if length==0
      then "OK\tБезопасные настройки: нарушений не найдено"
    else
      (["NAMESPACE","POD","CONT","REASON","IMAGE"],
       (.[] | [
         .ns, .pod, .cont,
         ([
            (if .privileged then "privileged" else empty end),
            (if .hostNetwork then "hostNetwork" else empty end),
            (if .hostPID then "hostPID" else empty end),
            (if .runAsRoot then "runAsRoot" else empty end),
            (if (.capAdd|index("SYS_ADMIN")) then "SYS_ADMIN" else empty end),
            (if (.capAdd|index("NET_ADMIN")) then "NET_ADMIN" else empty end)
          ] | join(",")),
         .img
       ]))
      | @tsv
    end
' | column -t

echo "--- Аудит завершен ---"
echo "Рекомендация: навесьте PSP/PSa, OPA/Gatekeeper/Kyverno и зафиксируйте политику по умолчанию (runAsNonRoot=true, drop ALL)."

Взгляд архитектора: Вы не охотитесь на последствия, вы контролируете «плоскость допуска» (admission). Скрипт — датчик, политика — предохранитель.

#kubernetes #security #sre #devops #bash #jq #скрипты

Переход на KubeVirt и ARM — это не мода, а экономика. Ты либо управляешь тысячей серверов как одной сущностью, либо тонешь в тикетах на «создание одной маленькой виртуалки». В 2026 году админ — это не «хранитель ключей от серверной», а архитектор автоматизированных фабрик по переработке трафика.

Золотое правило: Если систему нельзя описать одним YAML-файлом — эта система не должна существовать в твоем продакшене.

#собеседование_AF #kubevirt #arm #baremetal #virtualization #kubernetes #admin_future

По умолчанию Kubernetes Secrets хранятся в etcd только в формате base64, а не в зашифрованном виде. В продакшне необходимо включать шифрование данных at rest и ограничивать доступ через RBAC.

Base64 — это кодировка, а не шифрование. Любой, у кого есть доступ к etcd или к объекту Secret в API — видит пароль в открытом виде.

Как это исправить — три уровня защиты:

# Уровень 1: Включаем Encryption at Rest в etcd
# В конфиге kube-apiserver добавляем:
# --encryption-provider-config=/etc/kubernetes/enc/enc.yaml
# enc.yaml:
# resources:
#   - resources: ["secrets"]
#     providers:
#       - aescbc:
#           keys:
#             - name: key1
#               secret: <base64-encoded-32-byte-key>
#       - identity: {}

# Уровень 2: RBAC — минимальные права на чтение Secrets
kubectl create role secret-reader \
  --verb=get,list \
  --resource=secrets \
  --namespace=production

# Уровень 3 (продакшн-стандарт 2026): External Secrets Operator
# Secrets хранятся в Vault / AWS Secrets Manager / Azure Key Vault
# Kubernetes их НИКОГДА не держит у себя в etcd
# Манифест ExternalSecret:
# apiVersion: external-secrets.io/v1beta1
# kind: ExternalSecret
# spec:
#   secretStoreRef:
#     name: vault-backend
#   data:
#     - secretKey: db-password
#       remoteRef:
#         key: production/db
#         property: password

Секреты никогда не должны попадать в Git в открытом виде. Стандарт 2026 года: внешние хранилища (HashiCorp Vault, Cloud KMS) с инъекцией через External Secrets Operator или CSI-драйвер.

---

💡 Золотое правило собеса: Когда вас спрашивают про Kubernetes — интервьюер проверяет не знание синтаксиса kubectl, а понимание того, что происходит под капотом. Фраза "pod упал — я смотрю логи предыдущего запуска через --previous флаг, потому что текущие уже затёрты" — мгновенно выдаёт человека, который это делал в реальном продакшне, а не только читал документацию.

Сохраняйте пост — Kubernetes на собесах уже не опциональная тема!

#собеседование_AF #kubernetes #k8s #devops #sysadmin #контейнеры #admin_future

🐧 Linux: Cilium без kube-proxy — eBPF как замена iptables в Kubernetes

Коллеги, если у вас Kubernetes и kube-proxy на iptables — вы работаете с инструментом 2001 года. Не метафорически, буквально.

Проблема простая: iptables не был спроектирован для динамических сред. При каждом изменении Service или Endpoint правила перезаписываются целиком — на кластере из 500+ сервисов это создаёт заметную задержку и нагрузку на CPU.

Cilium в режиме kube-proxy replacement решает это через eBPF: таблицы маршрутизации хранятся в BPF maps, обновляются атомарно и обрабатываются прямо в ядре без userspace-прыжков.

# Устанавливаем Cilium с отключённым kube-proxy (k3s / kubeadm)
# При инициализации кластера убираем kube-proxy:
kubeadm init --skip-phases=addon/kube-proxy

# Устанавливаем Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true

# Проверяем что kube-proxy replacement активен
cilium status --verbose | grep -i "kube-proxy"
# KubeProxyReplacement: True

# Смотрим BPF-таблицы сервисов напрямую
cilium service list
cilium bpf lb list

# Мониторинг сетевых событий в реальном времени
cilium monitor --type drop

Зачем это нужно:
Cilium с eBPF даёт встроенную наблюдаемость L3/L4/L7 без sidecar-контейнеров, встроенный network policy без overhead iptables, и Hubble — визуализацию трафика между подами в реальном времени. Для кластеров от 50 нод разница в latency ощутима.

Итог: iptables в Kubernetes — это как держать Zabbix 2.0 вместо Prometheus. Работает, но не для 2026 года.

#linux #kubernetes #ebpf #cilium #networking #sysadmin #admin_future

🛡 ЧЕКЛИСТ ПО ЗАЩИТЕ CI/CD И КЛАСТЕРА
Защита веток (Branch Protection): жесткий запрет прямых пушей в main / master / release. Слияние — строго через Pull Request / Merge Request минимум с одним аппрувом.

Контроль CI-манифестов: любые правки в .gitlab-ci.yml, azure-pipelines.yml, Jenkinsfile требуют обязательного согласования (Code Owners) со стороны DevSecOps / инфраструктурной команды.

Отказ от статичных токенов: миграция на динамическую федерацию удостоверений через OpenID Connect (OIDC) с выдачей короткоживущих токенов. Никаких постоянных kubeconfig на файловой системе!

Принцип наименьших привилегий в K8s: гранулярные роли RBAC на каждый отдельный namespace. Запретить CI/CD-пайплайнам использовать глобальный cluster-admin.

Харденинг сборочных хостов: категорический запрет на запуск контейнеров с флагом --privileged и проброс /var/run/docker.sock. Ограничение исходящего трафика (Egress Firewall) только доверенными реестрами и репозиториями.

Алертинг на аномалии IAM: настройка триггеров на сброс паролей привилегированных пользователей, добавление новых устройств MFA и нетипичные изменения геопозиции входа.

#devops #cicd #kubernetes #gitlab #security #sysadmin #admin_future