Контейнери
Kubernetes: Оркестраторът, аргументиран честно
Kubernetes е оркестраторът на контейнери, който се превърна в субстрат на голяма система по подразбиране на инфраструктурата: внедрявания, услуги, вход, PersistentVolumes и API, който описва желаното състояние. Освен това е огромен. Честната статия за Kubernetes започва с това кога не трябва да се използва, след това обхваща истинската архитектура, опциите за хостинг (управляван срещу k3s) и операционната дисциплина, която изисква.
Ключови точки
- Основният обектен модел е наистина добър: внедряването описва желаното състояние на реплика, услугите осигуряват стабилна мрежа, ConfigMaps/Secrets отделна конфигурация, а Ingress достига навън; декларативното съгласуване (контролери, коригиращи дрейфа) е архитектурата, върху която се гради всичко останало.
- Оперативното тегло е реално: всеки от компонентите на контролната равнина (API сървър и т.н., планировчик, мениджър на контролер) се нуждае от HA и мониторинг; etcd резервните копия са единствената неприятна задача, която решава дали даден клъстер е възстановим; и дисциплината за надграждане (една второстепенна версия на стъпка, първо канарични възли) е постоянно задължение.
- Управляван срещу самоуправляващ се разклонител: GKE/EKS/AKS търговски контрол за намаляване на операциите, k3s/microk8s са законни мини-дистрибуции за малки флоти, а самоуправляващите се HA masters остават проект за голям екип; за хостинг бизнес k3s на шепа възли често е правилният таван.
- Съхранението е мястото, където повечето първи клъстери нараняват: PV/PVC в класовете за съхранение на различни облаци се различават, hostPath е крачка и класовете, поддържани от блоково съхранение, имат реална семантика на IOPS/скорост; планирайте класове за съхранение и стратегия за архивиране (velero-клас) преди първото работно натоварване със състояние.
- Работата в мрежа е собствена дисциплина: избор на CNI (фланела, калико, цилиум) контролно наслагване срещу естествено маршрутизиране и изходна политика; Ingress (nginx/traefik) плюс управление на TLS на сертификатния мениджър; пазарните инструменти се различават в зависимост от зрелостта на Gateway API; измерете преди да изберете.
- Честната присъда в нашата категория контейнери: приемете Kubernetes, когато графикът с множество възли, автоматичното мащабиране и управляваната от API автоматизация на внедряване носят работното натоварване; не k8s един WordPress сървър; Дистрибуциите от клас k3s разширяват зоната на полезност, но най-малките честни клъстери все още струват повече операции, отколкото композирането.
Бележка от терен
Клиентът, който „имаше нужда от Kubernetes“, се оказа, че се нуждае от точно четири услуги на два хоста и k3s им донесе контролен самолет, за да гледа дете за привилегията. Мигрирахме ги към обикновени стекове за композиране и техният дежурен пейджър замлъкна. Най-доброто решение за Kubernetes често е това, което не вземате.
Често задавани въпроси
Трябва ли нашият малък хостинг стек да се премести в Kubernetes?
Вероятно не: ако работните ви натоварвания са шепа услуги в шепа хостове, композираните или управляваните от Podman стекове са по-лесни за защита и наблюдение; изплащането на k8s започва с истински динамични нужди от планиране или автоматизация, управлявана от API в мащаб.
GKE, EKS, AKS или самоуправляващи се k3s?
Управляваните контролни равнини обменят контрол за разтоварени надстройки; k3s-клас за on-prem и тавани на разходите; самоуправляемият пълен Kubernetes е специален проект и рядко правилният отговор за хостинг бизнес профил.
Коя е най-честата оперативна повреда?
etcd остава без резервно копие: изтичането на сертификата в контролната равнина се показва следващо; третирайте резервното копие на клъстера (etcd snapshots или velero) като първото нещо, разгърнато след самия клъстер.
Как да защитим разумно клъстер?
RBAC с най-малка привилегия с реални роли на екип, мрежови политики, които действително сегментират трафика от пространството на имената, сканиране на изображения при допускане (кукички за политики на trivy-class) и тайни в клъстера, управлявани чрез вашия външен секретен мениджър, а не необработен YAML.
Как Kinetikatech помага с контейнери
Не е нужно да ставате експерт по контейнери: Управление, оркестрация и сигурност на контейнери в производствени среди. Точно затова съществува Сървърна администрация и Сигурност на Linux сървъра: въвеждане в експлоатация, укрепване, мониторинг и дежурен човек денонощно.