[Системное администрирование, *nix, DevOps, Kubernetes] Kubernetes-in-Kubernetes и ферма серверов с загрузкой по PXE
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Когда у вас 2 собственных дата-центра, тысячи железных серверов, виртуалки и хостинг для сотен тысяч сайтов, Kubernetes может существенно упростить управление всем этим добром. Как показала практика, с помощью Kubernetes можно декларативно описывать и управлять не только приложениями, но и самой инфраструктурой. Я работаю в крупнейшем чешском хостинг-провайдере WEDOS Internet a.s и сегодня расскажу о двух своих проектах — Kubernetes-in-Kubernetes и Kubefarm.С их помощью можно буквально за пару команд, используя Helm, развернуть полностью рабочий Kubernetes внутри другого Kubernetes-кластера. Как и зачем? Добро пожаловать под катИзвините, данный ресурс не поддреживается. :( Расскажу, как устроена наша инфраструктура. Все наши сервера можно разделить на две группы: control-plane и compute nodes. Control plane ноды, как правило, установлены вручную, имеют стабильную ОС и предназначены для запуска кластерных служб, в том числе и мастеров Kubernetes. Задача этих нод — обеспечивать бесперебойную работу самого кластера. Compute ноды не имеют никакой установленной операционки, а грузятся по сети прямо с control-plane нод. Их задача — выполнять полезную нагрузку.
На control-plane нодах задеплоены также PXE- и DHCP-серверы. Когда мы включаем наши compute-ноды, то первое, что они делают — обращаются к DHCP-серверу. Он, в свою очередь отвечает каждой ноде, условно говоря: «У тебя такой-то IP, грузись с такого-то PXE-сервера». После чего ноды скачивают образ системы и сохраняют его прямо в оперативную память, после чего продолжают загрузку непосредственно с него. Как только они загрузили этот образ, они могут продолжать работать и без связи с PXE-сервером. То есть PXE-сервер — это такая болванка, которая отдаёт образ и не содержит никакой более сложной логики. После того как наши ноды загрузились, мы можем спокойно перезагружать PXE-сервер, ничего критичного с ними уже не произойдет.
После загрузки системы первое, что делают наши ноды — это присоединяются к существующему Kubernetes-кластеру, а именно выполняют команду kubeadm join. Изначально они джойнились в тот же кластер, который использовался и для control-plane нод. После чего kube-scheduler мог шедуллить на них какие-нибудь поды и запускать различную рабочую нагрузку.
Эта схема стабильно работала у нас более двух лет. Позже мы решили добавить в неё контейнизированный Kubernetes. И теперь мы можем спавнить разные кластера на наших control-plane нодах (теперь они все находятся в специально отведенном admin-кластере). А compute-ноды джойнятся непосредственно каждая в свой кластер — в зависимости от её конфигурации.
KubefarmЭтот проект появился с целью, чтобы любой смог развернуть такую инфраструктуру за пару команд с помощью Helm и получить примерно то же самое.При этом мы ушли от идеи монокластера, потому что оказалось не очень удобно, когда с кластером работает несколько команд разработчиков. Дело в том, что Kubernetes никогда не задумывался как multi-tenant решение и на данный момент он не предоставляет достаточных средств изоляции между проектами. Поэтому запуск отдельных кластеров под каждую команду оказалось хорошим решением. Тем не менее, кластеров должно быть не слишком много, чтобы их по-прежнему было удобно обслуживать. И при этом не слишком мало, чтобы иметь достаточную независимость между командами разработки.Масштабируемость наших кластеров после этого стала заметно лучше — чем больше кластеров на количество нод у вас имеется, тем меньше домен отказа и тем стабильнее они работают. А в качестве бонуса мы получили полную декларативность. То есть теперь задеплоить новый Kubernetes-кластер можно точно так же, как и задеплоить любое другое приложение в Kubernetes.Так у нас получился проект Kubefarm. В качестве основы он использует Kubernetes-in-Kubernetes, LTSP — тот самый PXE-сервер, с которого грузятся ноды, и автоматизирует конфигурацию DHCP-сервера с помощью dnsmasq-controller:
Как это работаетТеперь посмотрим на то, как это работает. Вообще, если посмотреть на Kubernetes как на приложение — можно отметить что он соблюдает все принципы The Twelve-Factor App, и на самом деле написан довольно грамотно. Что означает — запустить его как приложение в другом Kubernetes не составляет особой проблемы.Запуск Kubernetes в Kubernetes
Давайте посмотрим на те параметры, которые мы передаем в Helm в values-файл:kubernetes/values.yaml
controlPlaneEndpoint:
persistence:
enabled: true
accessModes:
- ReadWriteOnce
size: 1Gi
# storageClassName: default
annotations: {}
finalizers:
- kubernetes.io/pvc-protection
backup:
# existingClaim: your-claim
# subPath: backups
accessModes:
- ReadWriteOnce
size: 1Gi
# storageClassName: default
annotations: {}
finalizers:
- kubernetes.io/pvc-protection
etcd:
enabled: true
image:
repository: k8s.gcr.io/etcd
tag: 3.4.13-0
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 3
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
certSANs:
dnsNames: []
ipAddresses: []
extraArgs: {}
# advertise-address is required for kube-proxy
#advertise-address: 10.9.8.10
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
ports:
client: 2379
peer: 2380
metrics: 2381
service:
enabled: true
type: ClusterIP
ports:
client: 2379
peer: 2380
metrics: 2381
labels: {}
annotations: {}
loadBalancerIP:
backup:
enabled: false
schedule: "0 */12 * * *"
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 3
extraArgs: #{}
debug: true
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAffinity: soft
podAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
apiServer:
enabled: true
image:
repository: k8s.gcr.io/kube-apiserver
tag: v1.20.5
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 2
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
certSANs:
dnsNames: []
ipAddresses: []
serviceClusterIPRange: 10.96.0.0/12
extraArgs: {}
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
port: 6443
service:
enabled: true
type: ClusterIP # NodePort / LoadBalancer
port: 6443
# Specify nodePort for apiserver service (30000-32767)
nodePort:
labels: {}
annotations: {}
loadBalancerIP:
controllerManager:
enabled: true
image:
repository: k8s.gcr.io/kube-controller-manager
tag: v1.20.5
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 2
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
extraArgs: {}
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
port: 10257
service:
enabled: true
type: ClusterIP
port: 10257
labels: {}
annotations: {}
loadBalancerIP:
scheduler:
enabled: true
image:
repository: k8s.gcr.io/kube-scheduler
tag: v1.20.5
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 2
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
extraArgs: {}
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
port: 10259
service:
enabled: true
type: ClusterIP
port: 10259
labels: {}
annotations: {}
loadBalancerIP:
admin:
enabled: true
image:
repository: ghcr.io/kvaps/kubernetes-tools
tag: v0.9.2
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 1
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
job:
enabled: true
schedule: "0 0 1 */6 *"
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 3
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
kubeProxy:
enabled: true
coredns:
enabled: true
konnectivityServer:
enabled: false
image:
repository: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server
tag: v0.0.14
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 2
resources:
requests:
cpu: 100m
memory: 128Mi
# limits:
# cpu: 100m
# memory: 128Mi
extraArgs: {}
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
ports:
server: 8131
agent: 8132
admin: 8133
health: 8134
service:
enabled: true
type: ClusterIP
ports:
server: 8131
agent: 8132
admin: 8133
nodePorts:
server:
agent:
admin:
labels: {}
annotations: {}
loadBalancerIP:
konnectivityAgent:
enabled: false
image:
repository: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent
tag: v0.0.14
pullPolicy: IfNotPresent
pullSecrets: []
replicaCount: 2
hostNetwork: true
extraArgs: {}
labels: {}
annotations: {}
podLabels: {}
podAnnotations: {}
nodeSelector: {}
tolerations: []
podAntiAffinity: soft
podAntiAffinityTopologyKey: kubernetes.io/hostname
affinity: {}
extraEnv: []
sidecars: []
extraVolumes: []
extraVolumeMounts: []
ports:
admin: 8133
health: 8134
# these manifests will be applied inside the cluster
extraManifests: {}
#namespace.yaml:
# apiVersion: v1
# kind: Namespace
# metadata:
# name: example
Помимо persistence (настроек хранения данных кластера) тут описаны компоненты нашего control-plane: а именно: etcd-кластер, apiserver, controller-manager и scheduler. Это в общем-то стандартные компоненты Kubernetes. Все мы знаем шутку, что Kubernetes — это всего 5 бинарей. Так вот здесь описывается конфигурация для этих самых бинарей. Если вы когда-то уже устанавливали кластер с помощью kubeadm, то этот конфиг вам его очень напомнит. Но помимо сущностей Kubernetes у нас есть еще admin-контейнер. По сути это контейнер, внутри которого находятся два бинарника: kubectl и kubeadm. Используются они для того, чтобы сгенерировать kubeconfig’и для вышеперечисленных компонентов и произвести начальную настройку кластера. Также, в случае чего, к нему всегда можно подключиться и посмотреть, что происходит внутри кластера.После того как релиз задеплоился, мы увидим список подов: admin-контейнер, apiserver в двух репликах, controller-manager, etcd-кластер, scheduller и та самая начальная джоба, которая инициализирует наш кластер. А в ответ мы получаем команду, выполнив которую сможем попасть в admin-контейнер и посмотреть, что там происходит:
Давайте ещё взглянем на сертификаты. Если вы когда-либо устанавливали Kubernetes, то вы знаете, что у него есть страшная папочка /etc/kubernetes/pki с кучей непонятных сертификатов. Но в нашем случае мы полностью автоматизировали управление ими. Достаточно передать в Helm, какие нам нужны сертификаты, и cert-manager автоматически сгенерирует их для нашего кластера.
Посмотрев на один из сертификатов, например для apiserver, можно увидеть что внутри него имеется список DNS-имен и IP-адресов. Если вы в дальнейшем захотите сделать этот кластер доступным извне, то просто опишите дополнительные DNS-имена в values-файле и обновите релиз — это обновит ресурс сертификата, а cert-manager его перевыпустит — и вам больше не придется думать об этом. Если в kubeadm сертификаты нужно обновлять не реже чем раз в год, то здесь cert-manager сам обновляет их автоматически по мере необходимости.
Теперь давайте залогинимся в admin-контейнер и посмотрим на наш кластер и ноды. Нод, конечно, пока нет, потому что на данный момент мы задеплоили только control-plane для Kubernetes. Но в kube-system уже появились пока никуда не зашедулленные coredns-поды и конфигмапы — то есть делаем вывод, что наш кластер работает:
Вот так выглядит схема задеплоеного кластера. Вы можете увидеть сервисы для всех компонентов Kubernetes: apiserver, controller-manager, etcd-кластер и scheduler. А справа — поды, в которые они ведут. Схема, кстати, нарисована в ArgoCD — GitOps-инструмент, который мы используем для управления кластерами, и классные схемы — одна из его фишек:
Оркестрация физических серверовОК, теперь у нас есть control-plane Kubernetes, но что насчёт worker-нод, как мы будем их добавлять? Как я уже говорил все сервера у нас bare metal — мы не используем виртуализацию для запуска Kubernetes, а оркестрируем все физические сервера самостоятельно.Плюс мы очень активно используем загрузку Linux по сети. Причем это именно загрузка, а не какая-то автоматизация установки: когда ноды загружаются, то грузят уже готовый имидж для них. То есть, чтобы обновить любую ноду, нам достаточно просто ее перезагрузить — и она скачает новый имидж. Это очень легко, просто и удобно.Для этого и был создан проект Kubefarm, который позволяет автоматизировать это. Наиболее часто используемые примеры вы сможете найти в директории examples. Самый стандартный из них — generic. Посмотрим на values.yaml:generic/values.yaml
# ------------------------------------------------------------------------------
# Kubernetes control-plane
# ------------------------------------------------------------------------------
kubernetes:
apiServer:
certSANs:
ipAddresses:
- 10.28.36.72
#dnsNames:
#- generic-cluster.example.org
extraArgs:
advertise-address: 10.28.36.72
# ------------------------------------------------------------------------------
# Network boot server configuration
# ------------------------------------------------------------------------------
ltsp:
config:
# from /usr/share/zoneinfo/<timezone> (eg. Europe/Moscow)
timezone: Europe/Prague
# SSH-keys authorized to access the nodes
sshAuthorizedKeys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSdizJARrlcOWVYswKPYbQ3FMa2eLJeE1utgUH7sDcOCsbpQh+Pu09biGkvO3QYGmeRXf64rQDx8adSf1Y/AutVJ6b044GEYoGWrenAPnt2VKyu7IrPvLr+0QLTuPsUPhKQToxs84j7eJ+Yzaro6etM2aPMlCuqHv9ZWFda198YQT3xr8ceAk6+Ni/q5vw5FDkmKtGVNl2UXHKovFxnGOkwYaPUlizTnj4WpK8e4FUQ95p75IQulGWGkL5RTbABhyFDuiVlGlW71qit79EaZDO4WA1tkdXYIQauIHQ073/ogI3YBlkD1QDsLXobjDHDaD3XMXK7lePudUkhiUng225 id_rsa
# Hashed password for root, use `openssl passwd -1` to generate one
rootPasswd: $1$jaKnTiEb$IhpsNUfssXQ8eQg8orald0 # hackme
# Modules to load during startup
modules:
- br_netfilter
- ip_vs
- ip_vs_rr
- ip_vs_wrr
- ip_vs_sh
# Extra options for ltsp.conf
options:
DEBUG_SHELL: 1
MENU_TIMEOUT: 0
KERNEL_PARAMETERS: "forcepae console=tty1 console=ttyS0,9600n8"
# ------------------------------------------------------------------------------
# Nodes configuration
# ------------------------------------------------------------------------------
nodePools:
-
# DHCP range for the node pool, required for issuing leases.
# See --dhcp-range option syntax on dnsmasq-man page.
# Note: the range will automatically be appended with the set:{{ .Release.Name }}-ltsp option.
#
# WARNING setting broadcast-address is required! (see: https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg14137.html)
range: 10.28.0.0,static,255.255.0.0,10.28.0.0,infinite
# DHCP configuration for each node
nodes:
- name: m1c29
mac: 94:57:a5:d3:ec:f2,94:57:a5:d3:ec:f3
ip: 10.28.36.173
- name: m1c31
mac: 94:57:a5:d3:ef:92,94:57:a5:d3:ef:93
ip: 10.28.36.174
- name: m1c35
mac: 94:57:a5:d3:d9:de,94:57:a5:d3:d9:df
ip: 10.28.36.175
- name: m1c37
mac: 94:57:a5:d3:ed:ee,94:57:a5:d3:ed:ef
ip: 10.28.36.176
- name: m1c41
mac: 94:57:a5:d3:f3:9e,94:57:a5:d3:f3:9f
ip: 10.28.36.177
- nodes:
- name: m1c43
mac: 94:57:a5:d3:ee:5a,94:57:a5:d3:ee:5b
ip: 10.28.36.178
tags:
- debug
- foo
# ------------------------------------------------------------------------------
# Extra options can be specified for each tag
# ("all" options are aplicable for any node)
# ------------------------------------------------------------------------------
tags:
dhcpOptions:
# dnsmasq options
# see all available options list (https://git.io/JJ0dH)
all:
router: 10.28.0.1
dns-server: 10.28.0.1
ltspOptions:
debug:
DEBUG_SHELL: "1"
kubernetesLabels:
all: {}
foo:
label1: value1
label2: value2
kubernetesTaints:
all: {}
foo:
- effect: NoSchedule
key: foo
value: bar
Здесь мы указываем параметры, которые прокидываются в вышестоящий чарт Kubernetes-in-Kubernetes. Для того чтобы наш control-plane был доступен снаружи здесь достаточно указать IP-адрес, но при желании можно указать и какое-нибудь DNS-имя.В конфигурации для PXE-сервера указываем какую-либо timezone. Можно еще добавить SSH-ключ для входа без пароля (но можно указать и пароль), а также модули и параметры ядра, которые должны использоваться при загрузке системы.Дальше идет конфигурация nodePools, т.е. самих нод. Если вы когда-то пользовались terraform-модулем для gke, то эта логика вам его напомнит. Здесь мы статически описываем все ноды набором параметров:
- Имя (host name);
- MAC-адрес — у нас ноды с двумя сетевыми карточками, и каждая может загрузиться с любого из указанных здесь MAC-адресов;
- IP-адрес, который DHCP-сервер должен выдать этой ноде.
В данном примере у нас два пула: в первом — пять нод, во втором — всего одна, но к нему добавлены еще два тэга конфигурации. Тэги — это способ описать конфигурацию для конкретных нод. Например, мы можем на какие-то пулы вешать отдельные DHCP-опции, опции для PXE-сервера для загрузки (здесь мы просто включаем debug) и пару опций KubernetesLabels и KubernetesTaints. Что это значит?Например, у нас есть nodePool с одной нодой, к которой добавлены тэги debug и foo. Смотрим KubernetesLabels, тэг foo. Это значит, что нода m1c43 загрузится с этими двумя установленными labels и с определенным taint. Вроде все просто. Теперь давайте сделаем это на практике.ДемоПереходим в examples и выполняем обновление нашего предыдущего задеплоенного чарта до Kubefarm. Устанавливаем из параметров generic и смотрим на поды. Видим, что у нас добавился PXE-сервер и одна джоба, которая по сути идет в Kubernetes и создаёт новый токен. Теперь она будет запускаться каждые 12 часов и генерировать новый токен для того, чтобы ноды могли подключиться в наш кластер.
Графически это выглядит примерно также, только теперь у нас apiserver стал смотреть наружу.
На схеме зеленым выделен IP, по которому стал доступен наш PXE-сервер. На данный момент Kubernetes по умолчанию не позволяет создавать единый LoadBalancer-сервис для TCP- и UDP-протоколов, поэтому приходится создавать два разных сервиса, но с одним IP-адресом. Один используется для TFTP, а второй для HTTP, по которым, собственно, и скачивается образ.Но этого не всегда бывает достаточно, и мы можем модифицировать логику при загрузке. Для примера есть директория advanced_network, внутри которого есть values-файл с простеньким shell-скриптом. У нас он называется network.sh.network.sh
# ------------------------------------------------------------------------------
# Network boot server configuration
# ------------------------------------------------------------------------------
ltsp:
config:
# Extra options for ltsp.conf
options:
POST_INIT_NETWORKING: ". /etc/ltsp/network.sh"
extraFiles:
network.sh: |
mask2cidr() {
nbits=0
IFS=.
for dec in $1 ; do
case $dec in
255) nbits=$((nbits+8));;
254) nbits=$((nbits+7));;
252) nbits=$((nbits+6));;
248) nbits=$((nbits+5));;
240) nbits=$((nbits+4));;
224) nbits=$((nbits+3));;
192) nbits=$((nbits+2));;
128) nbits=$((nbits+1));;
0);;
*) echo "Error: $dec is not recognised"; exit 1
esac
done
echo "$nbits"
}
set -e
# Load additional parameters
IPCONFIG_IPV4CIDR=$(mask2cidr $IPCONFIG_IPV4NETMASK)
DATA_IPV4ADDR=$(echo ${IPCONFIG_IPV4ADDR} | sed 's/^10\.28\./10.29./')
# Remove on-boot config
rm -rf /run/netplan
# Write new netplan config
mkdir -p /etc/netplan
cat >/etc/netplan/00-config.yaml <<EOT
network:
version: 2
renderer: networkd
ethernets:
eno1:
mtu: 9000
dhcp4: no
optional: true
eno1d1:
mtu: 9000
dhcp4: no
optional: true
bonds:
bond0:
mtu: 9000
dhcp4: no
macaddress: ${MAC_ADDRESS}
interfaces: [eno1, eno1d1]
parameters:
mode: 802.3ad
mii-monitor-interval: 100
down-delay: 200
up-delay: 200
lacp-rate: fast
transmit-hash-policy: layer3+4
ad-select: bandwidth
addresses: [${IPCONFIG_IPV4ADDR}/${IPCONFIG_IPV4CIDR}]
gateway4: ${IPCONFIG_IPV4GATEWAY}
vlans:
bond0.2:
addresses: [${DATA_IPV4ADDR}/${IPCONFIG_IPV4CIDR}]
id: 2
link: bond0
EOT
Все, что этот скрипт делает — берет переменные окружения во время загрузки, и исходя из них, генерирует конфигурацию для сети: создает директорию и кладет туда конфиг netplan. Например, тут создается bonding-интерфейс. В принципе, в этом скрипте может быть абсолютно все что угодно — от конфигурации сети до генерации системных сервисов и описания любой логики. Все, что можно описать в bash или в shell, можно положить сюда, и оно будет исполнено в момент загрузки.Посмотрим, как это можно задеплоить. Первым параметром мы передаём generic values-файл, а вторым параметром дополнительный values-файл. Для Helm — это стандартная возможность. Так можно, например, передавать секреты, но в нашем случае происходит расширение конфигурации:
Смотрим configmap foo-kubernetes-ltsp для нашего netboot-сервера и видим, что здесь находится наш скрипт network.sh и те самые команды использующиеся для конфигурации сети во время загрузки:
Здесь вы можете увидеть, как это работает в принципе. В интерфейсе шасси, где у нас находятся ноды (мы используем HPE Moonshots 1500), можно ввести команду show node list и увидеть список всех нод. Сейчас мы и будем их загружать.
Здесь также можно посмотреть их MAC-адреса — show node macaddr all. У нас есть хитрый оператор, который делает это автоматически. Эти адреса мы используем для конфигурации DHCP, копируя их в виде ресурсов для dnsmasq-controller в Kubernetes. И отсюда же мы можем управлять самими нодами, включать и выключать их.Если у вас нет такой же возможности, как у нас, чтобы зайти на шасси через iLO и собрать список MAC-адресов для всех нод, вы можете использовать паттерн с catchall-кластером — в нашем случае это просто кластер с динамическим DHCP-пулом. Таким образом все ноды, не описанные в конфигурации к другим кластерам, будут автоматически подключаться в этот кластер.
Например, здесь у нас уже есть какие-то ноды. Они добавляются в кластер с автоматически сгенерированным именем на основе MAC-адреса. Мы можем подключиться к ним и посмотреть, что там происходит. Здесь их можно как-то подготавливать, например нарезать файловую систему и после этого переподключать к другому кластеру.После подключения к ноде посмотрим, как происходит загрузка. После загрузки BIOS происходит конфигурация сетевой карты, здесь она с такого-то MAC-адреса отправляет запрос к DHCP-серверу, а тот ее отправляет на определенный PXE-сервер. По стандартному HTTP-протоколу ей отдаются ядро и initrd-образ:
После загрузки ядра нода скачивает initramfs-образ и передает управление systemd. Дальше загрузка идет как обычно, а сама нода присоединяется к Kubernetes:
Если посмотреть на fstab, то можно увидеть всего две записи: /var/lib/docker и /var/lib/kubelet, они смонтированы как tmpfs (по сути — из оперативной памяти). При этом корень у нас смонтирован как overlayfs, поэтому все изменения, которые вы сделаете здесь в системе, при следующей перезагрузке будут потеряны. Из блочных устройств на ноде есть один nvme-диск, но он пока что никуда не смонтирован. Есть также loop device — это тот самый initramfs-образ загруженный с сервера. На данный момент он лежит в оперативной памяти, занимает 653 Мб и смонтирован с опцией loop.Если посмотрим в /etc/ltsp, мы найдем наш файл network.sh, который был выполнен при загрузке. Из контейнеров у нас запустились kube-proxy, а также pause-контейнер для него.
ДеталиОбраз для загрузки по сетиНо откуда же берется основной образ? Здесь есть небольшая хитрость — образ для нод собирается через Dockerfile вместе с сервером. Возможность Docker multi-stage build позволяет легко добавлять любые пакеты и модули ядра именно на стадии сборки образа. Выглядит это так:Dockerfile
#-------------------------------------------------------------------------------
# Base part used for ltsp-server and ltsp-client
#-------------------------------------------------------------------------------
FROM ubuntu:20.04 as ltsp
ENV VERSION=v0.10.2
ENV DEBIAN_FRONTEND=noninteractive
# Install updates and LTSP package
RUN apt-get -y update \
&& apt-get -y upgrade \
&& apt-get -y install \
curl \
&& apt-get clean
RUN printf '%s\n' \
'deb http://ppa.launchpad.net/ltsp/ppa/ubuntu focal main' \
'deb http://ppa.launchpad.net/ltsp/proposed/ubuntu focal main' \
> /etc/apt/sources.list.d/ltsp.list \
&& curl -L https://ltsp.org/misc/ltsp_ubuntu_ppa.gpg \
-o /etc/apt/trusted.gpg.d/ltsp_ubuntu_ppa.gpg
RUN apt-get -y update \
&& apt-get -y install \
ltsp-cloud \
&& apt-get clean
#-------------------------------------------------------------------------------
# Installing Kernel and basic software
#-------------------------------------------------------------------------------
FROM ltsp as rootfs-pre
# Install packages
RUN echo 'APT::Install-Recommends "0";\nAPT::Install-Suggests "0";' \
>> /etc/apt/apt.conf.d/01norecommend \
&& mkdir -p /var/lib/resolvconf \
&& touch /var/lib/resolvconf/linkified \
&& apt-get update \
&& apt-get -y install \
adduser \
apparmor-utils \
apt-transport-https \
arping \
bash-completion \
bridge-utils \
ca-certificates \
curl \
dbus-user-session \
gnupg \
gpg-agent \
htop \
ifenslave \
initramfs-tools \
ipset \
ipvsadm \
jnettop \
jq \
linux-image-generic \
lm-sensors \
lvm2 \
openssh-server \
nano \
net-tools \
nfs-common \
pciutils \
resolvconf \
rsync \
screen \
squashfs-tools \
ssh \
sysstat \
systemd \
sudo \
tcpdump \
telnet \
thin-provisioning-tools \
ubuntu-minimal \
vim \
vlan \
wget \
zfsutils-linux \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# Disable systemd-resolved
RUN systemctl disable systemd-resolved.service \
&& systemctl mask systemd-resolved.service
# Install docker
ARG DOCKER_VERSION=20.10
RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - \
&& echo "deb https://download.docker.com/linux/ubuntu focal stable" \
> /etc/apt/sources.list.d/docker.list \
&& apt-get update \
&& DOCKER_VERSION=$(apt-cache madison docker-ce | awk '{print $3}' | grep -m1 "$DOCKER_VERSION") \
&& apt-get -y install docker-ce="$DOCKER_VERSION" \
&& apt-mark hold docker-ce
# Install kubeadm, kubelet and kubectl
# https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl
ARG KUBE_VERSION=1.20
RUN curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - \
&& echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" \
> /etc/apt/sources.list.d/kubernetes.list \
&& apt-get update \
&& KUBE_VERSION=$(apt-cache madison kubelet | awk '{print $3}' | grep -m1 "$KUBE_VERSION") \
&& apt-get -y install kubelet=$KUBE_VERSION kubeadm=$KUBE_VERSION kubectl=$KUBE_VERSION cri-tools \
&& apt-mark hold kubelet kubeadm kubectl
# Disable automatic updates
RUN rm -f /etc/apt/apt.conf.d/20auto-upgrades
# Disable apparmor profiles
RUN find /etc/apparmor.d \
-maxdepth 1 \
-type f \
-name "sbin.*" \
-o -name "usr.*" \
-exec ln -sf "{}" /etc/apparmor.d/disable/ \;
# Setup locales
RUN printf '%s\n' \
'LANG=en_US.UTF-8' \
'LC_TIME=en_DK.UTF-8' \
'LC_CTYPE=en_US.UTF-8' \
> /etc/locale.conf \
&& locale-gen en_US.UTF-8 en_DK.UTF-8
#-------------------------------------------------------------------------------
# Build kernel modules
#-------------------------------------------------------------------------------
FROM rootfs-pre as modules
# Install kernel-headers and dkms
RUN apt-get update \
&& KERNEL_VERSION="$(ls -1 /lib/modules/ | tail -n1)" \
&& apt-get -y install "linux-headers-${KERNEL_VERSION}" dkms \
&& apt-get clean
# Install DRBD modules
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CC1B5A793C04BB3905AD837734893610CEAA9512 \
&& echo "deb http://ppa.launchpad.net/linbit/linbit-drbd9-stack/ubuntu focal main" \
> /etc/apt/sources.list.d/linbit.list \
&& apt-get update \
&& apt-get -y install drbd-dkms
#-------------------------------------------------------------------------------
# Build rootfs image
#-------------------------------------------------------------------------------
FROM rootfs-pre as rootfs
# Copy kernel modules
COPY --from=modules /lib/modules/ /lib/modules/
# Generate initramfs with new modules
RUN update-initramfs -u
# Generate motd
COPY motd /etc/motd
RUN sed -i "s/\${VERSION}/${VERSION}/" /etc/motd
# Generate image
ENV OMIT_FUNCTIONS="remove_users"
RUN ltsp image -I /
#-------------------------------------------------------------------------------
# Build dnsmasq with tftp single port support
#-------------------------------------------------------------------------------
FROM ltsp as builder
# Common build-dependencies
RUN apt-get -y update \
&& apt-get -y install \
git \
build-essential \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* \
# Build dnsmasq
ARG DNSMAQ_VERSION=2.81-12-g619000a
RUN git clone git://thekelleys.org.uk/dnsmasq.git \
&& cd dnsmasq/ \
&& git checkout ${DNSMAQ_VERSION} \
&& make
#-------------------------------------------------------------------------------
# LTSP-Server
#-------------------------------------------------------------------------------
FROM ltsp
RUN apt-get -y update \
&& apt-get -y install \
grub-pc-bin \
grub-efi-amd64-bin \
inotify-tools \
nginx \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# Generate nginx config
RUN ltsp http -I
COPY --from=builder /dnsmasq/src/dnsmasq /usr/sbin/dnsmasq
COPY --from=rootfs /srv/ltsp/images /srv/ltsp/images
COPY --from=rootfs /srv/tftp/ltsp /srv/tftp/ltsp
Что здесь происходит? Во-первых, мы берем обычную Ubuntu 20.04 и устанавливаем туда все необходимые нам пакеты. В первую очередь — ядро, lvm, systemd, SSH — в общем, всё то, что вы хотите увидеть на окончательной ноде. Для этого есть отдельный stage. Здесь мы также устанавливаем Docker с Kubernetes kubelet и kubeadm, которые используются для джойна ноды к кластеру.А дальше производим дополнительную настройку. В последнем stage мы просто устанавливаем туда tftp с nginx (которые отдают наш образ клиентам), grub (наш загрузчик), и в этот же образ копируем корень предыдущих stages. То есть по сути у нас получается образ, внутри которого находится как сервер, так и загрузочный образ для наших нод. В тоже время, изменяя Dockerfile, его можно легко обновить.Вебхуки и API aggregation layerapiserverОтдельное внимание хочу уделить проблеме вебхуков и aggregation layer. Вообще вебхуки — это возможность Kubernetes, которая позволяет реагировать на создание или изменение каких-либо ресурсов. То есть можно повесить обработчик, чтобы при применении ресурсов Kubernetes ходил к какому-нибудь поду и проверял, верна ли его конфигурация, или вносил бы в него дополнительные изменения. Но дело в том, что для работы вебхуков apiserver должен иметь доступ непосредственно к кластеру, в которым он работает. А если он запущен в отдельном кластере, как у нас, или вообще отдельно от кластера, то здесь нам может помочь Konnectivity. Konnectivity — это один из необязательных, но официально поддерживаемых компонентов Kubernetes.Возьмем для примера 4 ноды, на каждой из которых запущен kubelet и другие компоненты Kubernetes: apiserver, scheduller и controller-manager. По умолчанию все эти компоненты ходят и взаимодействуют с apiserver’ом напрямую — это наиболее понятная часть логики работы Kubernetes. Но на самом деле есть ещё и обратный режим. Например, иногда, когда вы хотите посмотреть логи какого-то пода или выполнить kubectl exec, то apiserver самостоятельно устанавливает соединение с каким-либо из kubelet’ов:
Но проблема в том, что если у нас есть вебхук, то он, как правило, запущен в виде стандартного пода с сервисом в нашем кластере. И когда apiserver попробует к нему достучаться, то у него ничего не получится — потому что он будет пытаться обратиться к in-cluster сервису по имени webhook.namespace.svc:
И здесь нам на помощь приходит Konnectivity — хитрый прокси-сервер созданный специально для Kubernetes. Он деплоится в виде сервера рядом с apiserver. А Konnectivity-agent деплоится уже непосредственно в кластере, в который вы хотите ходить, также в нескольких репликах. Агент устанавливает подключение к серверу и позволяет apiserver наладить стабильный канал, чтобы тот смог ходить через него и имел возможность обращаться со всеми вебхуками и всеми kubelet’ам в кластере. Таким образом теперь всё общение с кластером будет происходить через Konnectivity-server:
Наши планыКонечно, на этом этапе мы останавливаться не собираемся. Мне достаточно часто пишут заинтересованные в проекте люди. И если наберется критическая масса, я надеюсь переместить Kubernetes-in-Kubernetes под крыло Kubernetes-SIGs, представив его в виде официального Kubernetes Helm-чарта. И, возможно, так мы соберем ещё большее комьюнити. Также я подумываю сделать интеграцию с Machine Controller Manager, что позволило бы создавать worker’ы, не только на физических серверах, а например создавать виртуалки используя kubevirt и запускать их в том же Kubernetes-кластере. Им кстати, можно также создавать виртуалки в облаках, имея control-plane, задеплоенный у себя локально. Также я рассматриваю вариант интеграции с Cluster-API, чтобы можно было создавать физические кластера Kubefarm прямо через окружение Kubernetes. Но на данный момент я не до конца уверен в этой идее. Если у вас есть мысли на этот счет, с радостью их выслушаю.
В этом году DevOpsConf пройдёт в гибридном формате. Это значит, что и онлайн- и офлайн-участники смогут общаться с партнёрами конференции, задавать вопросы спикерам и участвовать в активностях в зоне выставки.Бронируйте билеты и присоединяйтесь к сообществу фанатов DevOps-подхода! Расписание здесь.
===========
Источник:
habr.com
===========
Похожие новости:
- [Настройка Linux, *nix] Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным
- [Облачные сервисы, IT-компании, Kubernetes] Kubernetes как сервис — изучение рынка
- [Open source, Системное администрирование, PostgreSQL, IT-инфраструктура] Мониторинг 95+ метрик PostgreSQL с помощью плагина Zabbix Agent 2
- [Системное администрирование, Сетевые технологии, Сетевое оборудование] Настройка IGMP proxy на FortiWiFi 30E версия FortiOS 6.2.5
- [Google Chrome, Расширения для браузеров, Браузеры, Разработка под Linux, Разработка под Windows] Google выпустила исправления для Chrome после сбоев на Windows 10 и Linux
- [Системное администрирование, DevOps, Микросервисы, Kubernetes] Service Mesh Wars, прощаемся с Istio (перевод)
- Опубликован AV Linux 2021.05.22, дистрибутив для создания аудио- и видеоконтента
- [Управление разработкой, Управление проектами, Agile, Управление продуктом, Карьера в IT-индустрии] Гайд по сертификациям. Часть 1. Agile
- [Разработка под Linux, История IT, Старое железо] Вышел Floppinux 0.1.0 — дистрибутив Linux, умещающийся на одной 3.5-дюймовой дискете
- [Системное администрирование, PostgreSQL, Администрирование баз данных] Что нового в плане мониторинга в PostgreSQL 14
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_*nix, #_devops, #_kubernetes, #_kubernetes, #_pxe, #_linux, #_docker, #_ltsp, #_infrastruktura (инфраструктура), #_infrastructure, #_infrastructure_as_code, #_infrastruktura_kak_kod (инфраструктура как код), #_helm, #_blog_kompanii_konferentsii_olega_bunina_(ontiko) (
Блог компании Конференции Олега Бунина (Онтико)
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_*nix, #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:40
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Когда у вас 2 собственных дата-центра, тысячи железных серверов, виртуалки и хостинг для сотен тысяч сайтов, Kubernetes может существенно упростить управление всем этим добром. Как показала практика, с помощью Kubernetes можно декларативно описывать и управлять не только приложениями, но и самой инфраструктурой. Я работаю в крупнейшем чешском хостинг-провайдере WEDOS Internet a.s и сегодня расскажу о двух своих проектах — Kubernetes-in-Kubernetes и Kubefarm.С их помощью можно буквально за пару команд, используя Helm, развернуть полностью рабочий Kubernetes внутри другого Kubernetes-кластера. Как и зачем? Добро пожаловать под катИзвините, данный ресурс не поддреживается. :( Расскажу, как устроена наша инфраструктура. Все наши сервера можно разделить на две группы: control-plane и compute nodes. Control plane ноды, как правило, установлены вручную, имеют стабильную ОС и предназначены для запуска кластерных служб, в том числе и мастеров Kubernetes. Задача этих нод — обеспечивать бесперебойную работу самого кластера. Compute ноды не имеют никакой установленной операционки, а грузятся по сети прямо с control-plane нод. Их задача — выполнять полезную нагрузку. На control-plane нодах задеплоены также PXE- и DHCP-серверы. Когда мы включаем наши compute-ноды, то первое, что они делают — обращаются к DHCP-серверу. Он, в свою очередь отвечает каждой ноде, условно говоря: «У тебя такой-то IP, грузись с такого-то PXE-сервера». После чего ноды скачивают образ системы и сохраняют его прямо в оперативную память, после чего продолжают загрузку непосредственно с него. Как только они загрузили этот образ, они могут продолжать работать и без связи с PXE-сервером. То есть PXE-сервер — это такая болванка, которая отдаёт образ и не содержит никакой более сложной логики. После того как наши ноды загрузились, мы можем спокойно перезагружать PXE-сервер, ничего критичного с ними уже не произойдет. После загрузки системы первое, что делают наши ноды — это присоединяются к существующему Kubernetes-кластеру, а именно выполняют команду kubeadm join. Изначально они джойнились в тот же кластер, который использовался и для control-plane нод. После чего kube-scheduler мог шедуллить на них какие-нибудь поды и запускать различную рабочую нагрузку. Эта схема стабильно работала у нас более двух лет. Позже мы решили добавить в неё контейнизированный Kubernetes. И теперь мы можем спавнить разные кластера на наших control-plane нодах (теперь они все находятся в специально отведенном admin-кластере). А compute-ноды джойнятся непосредственно каждая в свой кластер — в зависимости от её конфигурации. KubefarmЭтот проект появился с целью, чтобы любой смог развернуть такую инфраструктуру за пару команд с помощью Helm и получить примерно то же самое.При этом мы ушли от идеи монокластера, потому что оказалось не очень удобно, когда с кластером работает несколько команд разработчиков. Дело в том, что Kubernetes никогда не задумывался как multi-tenant решение и на данный момент он не предоставляет достаточных средств изоляции между проектами. Поэтому запуск отдельных кластеров под каждую команду оказалось хорошим решением. Тем не менее, кластеров должно быть не слишком много, чтобы их по-прежнему было удобно обслуживать. И при этом не слишком мало, чтобы иметь достаточную независимость между командами разработки.Масштабируемость наших кластеров после этого стала заметно лучше — чем больше кластеров на количество нод у вас имеется, тем меньше домен отказа и тем стабильнее они работают. А в качестве бонуса мы получили полную декларативность. То есть теперь задеплоить новый Kubernetes-кластер можно точно так же, как и задеплоить любое другое приложение в Kubernetes.Так у нас получился проект Kubefarm. В качестве основы он использует Kubernetes-in-Kubernetes, LTSP — тот самый PXE-сервер, с которого грузятся ноды, и автоматизирует конфигурацию DHCP-сервера с помощью dnsmasq-controller: Как это работаетТеперь посмотрим на то, как это работает. Вообще, если посмотреть на Kubernetes как на приложение — можно отметить что он соблюдает все принципы The Twelve-Factor App, и на самом деле написан довольно грамотно. Что означает — запустить его как приложение в другом Kubernetes не составляет особой проблемы.Запуск Kubernetes в Kubernetes Давайте посмотрим на те параметры, которые мы передаем в Helm в values-файл:kubernetes/values.yaml controlPlaneEndpoint:
persistence: enabled: true accessModes: - ReadWriteOnce size: 1Gi # storageClassName: default annotations: {} finalizers: - kubernetes.io/pvc-protection backup: # existingClaim: your-claim # subPath: backups accessModes: - ReadWriteOnce size: 1Gi # storageClassName: default annotations: {} finalizers: - kubernetes.io/pvc-protection etcd: enabled: true image: repository: k8s.gcr.io/etcd tag: 3.4.13-0 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 3 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi certSANs: dnsNames: [] ipAddresses: [] extraArgs: {} # advertise-address is required for kube-proxy #advertise-address: 10.9.8.10 labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] ports: client: 2379 peer: 2380 metrics: 2381 service: enabled: true type: ClusterIP ports: client: 2379 peer: 2380 metrics: 2381 labels: {} annotations: {} loadBalancerIP: backup: enabled: false schedule: "0 */12 * * *" successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 3 extraArgs: #{} debug: true resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAffinity: soft podAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] apiServer: enabled: true image: repository: k8s.gcr.io/kube-apiserver tag: v1.20.5 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 2 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi certSANs: dnsNames: [] ipAddresses: [] serviceClusterIPRange: 10.96.0.0/12 extraArgs: {} labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] port: 6443 service: enabled: true type: ClusterIP # NodePort / LoadBalancer port: 6443 # Specify nodePort for apiserver service (30000-32767) nodePort: labels: {} annotations: {} loadBalancerIP: controllerManager: enabled: true image: repository: k8s.gcr.io/kube-controller-manager tag: v1.20.5 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 2 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi extraArgs: {} labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] port: 10257 service: enabled: true type: ClusterIP port: 10257 labels: {} annotations: {} loadBalancerIP: scheduler: enabled: true image: repository: k8s.gcr.io/kube-scheduler tag: v1.20.5 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 2 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi extraArgs: {} labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] port: 10259 service: enabled: true type: ClusterIP port: 10259 labels: {} annotations: {} loadBalancerIP: admin: enabled: true image: repository: ghcr.io/kvaps/kubernetes-tools tag: v0.9.2 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 1 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi job: enabled: true schedule: "0 0 1 */6 *" successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 3 labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] kubeProxy: enabled: true coredns: enabled: true konnectivityServer: enabled: false image: repository: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server tag: v0.0.14 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 2 resources: requests: cpu: 100m memory: 128Mi # limits: # cpu: 100m # memory: 128Mi extraArgs: {} labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] ports: server: 8131 agent: 8132 admin: 8133 health: 8134 service: enabled: true type: ClusterIP ports: server: 8131 agent: 8132 admin: 8133 nodePorts: server: agent: admin: labels: {} annotations: {} loadBalancerIP: konnectivityAgent: enabled: false image: repository: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent tag: v0.0.14 pullPolicy: IfNotPresent pullSecrets: [] replicaCount: 2 hostNetwork: true extraArgs: {} labels: {} annotations: {} podLabels: {} podAnnotations: {} nodeSelector: {} tolerations: [] podAntiAffinity: soft podAntiAffinityTopologyKey: kubernetes.io/hostname affinity: {} extraEnv: [] sidecars: [] extraVolumes: [] extraVolumeMounts: [] ports: admin: 8133 health: 8134 # these manifests will be applied inside the cluster extraManifests: {} #namespace.yaml: # apiVersion: v1 # kind: Namespace # metadata: # name: example Помимо persistence (настроек хранения данных кластера) тут описаны компоненты нашего control-plane: а именно: etcd-кластер, apiserver, controller-manager и scheduler. Это в общем-то стандартные компоненты Kubernetes. Все мы знаем шутку, что Kubernetes — это всего 5 бинарей. Так вот здесь описывается конфигурация для этих самых бинарей. Если вы когда-то уже устанавливали кластер с помощью kubeadm, то этот конфиг вам его очень напомнит. Но помимо сущностей Kubernetes у нас есть еще admin-контейнер. По сути это контейнер, внутри которого находятся два бинарника: kubectl и kubeadm. Используются они для того, чтобы сгенерировать kubeconfig’и для вышеперечисленных компонентов и произвести начальную настройку кластера. Также, в случае чего, к нему всегда можно подключиться и посмотреть, что происходит внутри кластера.После того как релиз задеплоился, мы увидим список подов: admin-контейнер, apiserver в двух репликах, controller-manager, etcd-кластер, scheduller и та самая начальная джоба, которая инициализирует наш кластер. А в ответ мы получаем команду, выполнив которую сможем попасть в admin-контейнер и посмотреть, что там происходит: Давайте ещё взглянем на сертификаты. Если вы когда-либо устанавливали Kubernetes, то вы знаете, что у него есть страшная папочка /etc/kubernetes/pki с кучей непонятных сертификатов. Но в нашем случае мы полностью автоматизировали управление ими. Достаточно передать в Helm, какие нам нужны сертификаты, и cert-manager автоматически сгенерирует их для нашего кластера. Посмотрев на один из сертификатов, например для apiserver, можно увидеть что внутри него имеется список DNS-имен и IP-адресов. Если вы в дальнейшем захотите сделать этот кластер доступным извне, то просто опишите дополнительные DNS-имена в values-файле и обновите релиз — это обновит ресурс сертификата, а cert-manager его перевыпустит — и вам больше не придется думать об этом. Если в kubeadm сертификаты нужно обновлять не реже чем раз в год, то здесь cert-manager сам обновляет их автоматически по мере необходимости. Теперь давайте залогинимся в admin-контейнер и посмотрим на наш кластер и ноды. Нод, конечно, пока нет, потому что на данный момент мы задеплоили только control-plane для Kubernetes. Но в kube-system уже появились пока никуда не зашедулленные coredns-поды и конфигмапы — то есть делаем вывод, что наш кластер работает: Вот так выглядит схема задеплоеного кластера. Вы можете увидеть сервисы для всех компонентов Kubernetes: apiserver, controller-manager, etcd-кластер и scheduler. А справа — поды, в которые они ведут. Схема, кстати, нарисована в ArgoCD — GitOps-инструмент, который мы используем для управления кластерами, и классные схемы — одна из его фишек: Оркестрация физических серверовОК, теперь у нас есть control-plane Kubernetes, но что насчёт worker-нод, как мы будем их добавлять? Как я уже говорил все сервера у нас bare metal — мы не используем виртуализацию для запуска Kubernetes, а оркестрируем все физические сервера самостоятельно.Плюс мы очень активно используем загрузку Linux по сети. Причем это именно загрузка, а не какая-то автоматизация установки: когда ноды загружаются, то грузят уже готовый имидж для них. То есть, чтобы обновить любую ноду, нам достаточно просто ее перезагрузить — и она скачает новый имидж. Это очень легко, просто и удобно.Для этого и был создан проект Kubefarm, который позволяет автоматизировать это. Наиболее часто используемые примеры вы сможете найти в директории examples. Самый стандартный из них — generic. Посмотрим на values.yaml:generic/values.yaml # ------------------------------------------------------------------------------
# Kubernetes control-plane # ------------------------------------------------------------------------------ kubernetes: apiServer: certSANs: ipAddresses: - 10.28.36.72 #dnsNames: #- generic-cluster.example.org extraArgs: advertise-address: 10.28.36.72 # ------------------------------------------------------------------------------ # Network boot server configuration # ------------------------------------------------------------------------------ ltsp: config: # from /usr/share/zoneinfo/<timezone> (eg. Europe/Moscow) timezone: Europe/Prague # SSH-keys authorized to access the nodes sshAuthorizedKeys: - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSdizJARrlcOWVYswKPYbQ3FMa2eLJeE1utgUH7sDcOCsbpQh+Pu09biGkvO3QYGmeRXf64rQDx8adSf1Y/AutVJ6b044GEYoGWrenAPnt2VKyu7IrPvLr+0QLTuPsUPhKQToxs84j7eJ+Yzaro6etM2aPMlCuqHv9ZWFda198YQT3xr8ceAk6+Ni/q5vw5FDkmKtGVNl2UXHKovFxnGOkwYaPUlizTnj4WpK8e4FUQ95p75IQulGWGkL5RTbABhyFDuiVlGlW71qit79EaZDO4WA1tkdXYIQauIHQ073/ogI3YBlkD1QDsLXobjDHDaD3XMXK7lePudUkhiUng225 id_rsa # Hashed password for root, use `openssl passwd -1` to generate one rootPasswd: $1$jaKnTiEb$IhpsNUfssXQ8eQg8orald0 # hackme # Modules to load during startup modules: - br_netfilter - ip_vs - ip_vs_rr - ip_vs_wrr - ip_vs_sh # Extra options for ltsp.conf options: DEBUG_SHELL: 1 MENU_TIMEOUT: 0 KERNEL_PARAMETERS: "forcepae console=tty1 console=ttyS0,9600n8" # ------------------------------------------------------------------------------ # Nodes configuration # ------------------------------------------------------------------------------ nodePools: - # DHCP range for the node pool, required for issuing leases. # See --dhcp-range option syntax on dnsmasq-man page. # Note: the range will automatically be appended with the set:{{ .Release.Name }}-ltsp option. # # WARNING setting broadcast-address is required! (see: https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg14137.html) range: 10.28.0.0,static,255.255.0.0,10.28.0.0,infinite # DHCP configuration for each node nodes: - name: m1c29 mac: 94:57:a5:d3:ec:f2,94:57:a5:d3:ec:f3 ip: 10.28.36.173 - name: m1c31 mac: 94:57:a5:d3:ef:92,94:57:a5:d3:ef:93 ip: 10.28.36.174 - name: m1c35 mac: 94:57:a5:d3:d9:de,94:57:a5:d3:d9:df ip: 10.28.36.175 - name: m1c37 mac: 94:57:a5:d3:ed:ee,94:57:a5:d3:ed:ef ip: 10.28.36.176 - name: m1c41 mac: 94:57:a5:d3:f3:9e,94:57:a5:d3:f3:9f ip: 10.28.36.177 - nodes: - name: m1c43 mac: 94:57:a5:d3:ee:5a,94:57:a5:d3:ee:5b ip: 10.28.36.178 tags: - debug - foo # ------------------------------------------------------------------------------ # Extra options can be specified for each tag # ("all" options are aplicable for any node) # ------------------------------------------------------------------------------ tags: dhcpOptions: # dnsmasq options # see all available options list (https://git.io/JJ0dH) all: router: 10.28.0.1 dns-server: 10.28.0.1 ltspOptions: debug: DEBUG_SHELL: "1" kubernetesLabels: all: {} foo: label1: value1 label2: value2 kubernetesTaints: all: {} foo: - effect: NoSchedule key: foo value: bar
Графически это выглядит примерно также, только теперь у нас apiserver стал смотреть наружу. На схеме зеленым выделен IP, по которому стал доступен наш PXE-сервер. На данный момент Kubernetes по умолчанию не позволяет создавать единый LoadBalancer-сервис для TCP- и UDP-протоколов, поэтому приходится создавать два разных сервиса, но с одним IP-адресом. Один используется для TFTP, а второй для HTTP, по которым, собственно, и скачивается образ.Но этого не всегда бывает достаточно, и мы можем модифицировать логику при загрузке. Для примера есть директория advanced_network, внутри которого есть values-файл с простеньким shell-скриптом. У нас он называется network.sh.network.sh # ------------------------------------------------------------------------------
# Network boot server configuration # ------------------------------------------------------------------------------ ltsp: config: # Extra options for ltsp.conf options: POST_INIT_NETWORKING: ". /etc/ltsp/network.sh" extraFiles: network.sh: | mask2cidr() { nbits=0 IFS=. for dec in $1 ; do case $dec in 255) nbits=$((nbits+8));; 254) nbits=$((nbits+7));; 252) nbits=$((nbits+6));; 248) nbits=$((nbits+5));; 240) nbits=$((nbits+4));; 224) nbits=$((nbits+3));; 192) nbits=$((nbits+2));; 128) nbits=$((nbits+1));; 0);; *) echo "Error: $dec is not recognised"; exit 1 esac done echo "$nbits" } set -e # Load additional parameters IPCONFIG_IPV4CIDR=$(mask2cidr $IPCONFIG_IPV4NETMASK) DATA_IPV4ADDR=$(echo ${IPCONFIG_IPV4ADDR} | sed 's/^10\.28\./10.29./') # Remove on-boot config rm -rf /run/netplan # Write new netplan config mkdir -p /etc/netplan cat >/etc/netplan/00-config.yaml <<EOT network: version: 2 renderer: networkd ethernets: eno1: mtu: 9000 dhcp4: no optional: true eno1d1: mtu: 9000 dhcp4: no optional: true bonds: bond0: mtu: 9000 dhcp4: no macaddress: ${MAC_ADDRESS} interfaces: [eno1, eno1d1] parameters: mode: 802.3ad mii-monitor-interval: 100 down-delay: 200 up-delay: 200 lacp-rate: fast transmit-hash-policy: layer3+4 ad-select: bandwidth addresses: [${IPCONFIG_IPV4ADDR}/${IPCONFIG_IPV4CIDR}] gateway4: ${IPCONFIG_IPV4GATEWAY} vlans: bond0.2: addresses: [${DATA_IPV4ADDR}/${IPCONFIG_IPV4CIDR}] id: 2 link: bond0 EOT Смотрим configmap foo-kubernetes-ltsp для нашего netboot-сервера и видим, что здесь находится наш скрипт network.sh и те самые команды использующиеся для конфигурации сети во время загрузки: Здесь вы можете увидеть, как это работает в принципе. В интерфейсе шасси, где у нас находятся ноды (мы используем HPE Moonshots 1500), можно ввести команду show node list и увидеть список всех нод. Сейчас мы и будем их загружать. Здесь также можно посмотреть их MAC-адреса — show node macaddr all. У нас есть хитрый оператор, который делает это автоматически. Эти адреса мы используем для конфигурации DHCP, копируя их в виде ресурсов для dnsmasq-controller в Kubernetes. И отсюда же мы можем управлять самими нодами, включать и выключать их.Если у вас нет такой же возможности, как у нас, чтобы зайти на шасси через iLO и собрать список MAC-адресов для всех нод, вы можете использовать паттерн с catchall-кластером — в нашем случае это просто кластер с динамическим DHCP-пулом. Таким образом все ноды, не описанные в конфигурации к другим кластерам, будут автоматически подключаться в этот кластер. Например, здесь у нас уже есть какие-то ноды. Они добавляются в кластер с автоматически сгенерированным именем на основе MAC-адреса. Мы можем подключиться к ним и посмотреть, что там происходит. Здесь их можно как-то подготавливать, например нарезать файловую систему и после этого переподключать к другому кластеру.После подключения к ноде посмотрим, как происходит загрузка. После загрузки BIOS происходит конфигурация сетевой карты, здесь она с такого-то MAC-адреса отправляет запрос к DHCP-серверу, а тот ее отправляет на определенный PXE-сервер. По стандартному HTTP-протоколу ей отдаются ядро и initrd-образ: После загрузки ядра нода скачивает initramfs-образ и передает управление systemd. Дальше загрузка идет как обычно, а сама нода присоединяется к Kubernetes: Если посмотреть на fstab, то можно увидеть всего две записи: /var/lib/docker и /var/lib/kubelet, они смонтированы как tmpfs (по сути — из оперативной памяти). При этом корень у нас смонтирован как overlayfs, поэтому все изменения, которые вы сделаете здесь в системе, при следующей перезагрузке будут потеряны. Из блочных устройств на ноде есть один nvme-диск, но он пока что никуда не смонтирован. Есть также loop device — это тот самый initramfs-образ загруженный с сервера. На данный момент он лежит в оперативной памяти, занимает 653 Мб и смонтирован с опцией loop.Если посмотрим в /etc/ltsp, мы найдем наш файл network.sh, который был выполнен при загрузке. Из контейнеров у нас запустились kube-proxy, а также pause-контейнер для него. ДеталиОбраз для загрузки по сетиНо откуда же берется основной образ? Здесь есть небольшая хитрость — образ для нод собирается через Dockerfile вместе с сервером. Возможность Docker multi-stage build позволяет легко добавлять любые пакеты и модули ядра именно на стадии сборки образа. Выглядит это так:Dockerfile #-------------------------------------------------------------------------------
# Base part used for ltsp-server and ltsp-client #------------------------------------------------------------------------------- FROM ubuntu:20.04 as ltsp ENV VERSION=v0.10.2 ENV DEBIAN_FRONTEND=noninteractive # Install updates and LTSP package RUN apt-get -y update \ && apt-get -y upgrade \ && apt-get -y install \ curl \ && apt-get clean RUN printf '%s\n' \ 'deb http://ppa.launchpad.net/ltsp/ppa/ubuntu focal main' \ 'deb http://ppa.launchpad.net/ltsp/proposed/ubuntu focal main' \ > /etc/apt/sources.list.d/ltsp.list \ && curl -L https://ltsp.org/misc/ltsp_ubuntu_ppa.gpg \ -o /etc/apt/trusted.gpg.d/ltsp_ubuntu_ppa.gpg RUN apt-get -y update \ && apt-get -y install \ ltsp-cloud \ && apt-get clean #------------------------------------------------------------------------------- # Installing Kernel and basic software #------------------------------------------------------------------------------- FROM ltsp as rootfs-pre # Install packages RUN echo 'APT::Install-Recommends "0";\nAPT::Install-Suggests "0";' \ >> /etc/apt/apt.conf.d/01norecommend \ && mkdir -p /var/lib/resolvconf \ && touch /var/lib/resolvconf/linkified \ && apt-get update \ && apt-get -y install \ adduser \ apparmor-utils \ apt-transport-https \ arping \ bash-completion \ bridge-utils \ ca-certificates \ curl \ dbus-user-session \ gnupg \ gpg-agent \ htop \ ifenslave \ initramfs-tools \ ipset \ ipvsadm \ jnettop \ jq \ linux-image-generic \ lm-sensors \ lvm2 \ openssh-server \ nano \ net-tools \ nfs-common \ pciutils \ resolvconf \ rsync \ screen \ squashfs-tools \ ssh \ sysstat \ systemd \ sudo \ tcpdump \ telnet \ thin-provisioning-tools \ ubuntu-minimal \ vim \ vlan \ wget \ zfsutils-linux \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # Disable systemd-resolved RUN systemctl disable systemd-resolved.service \ && systemctl mask systemd-resolved.service # Install docker ARG DOCKER_VERSION=20.10 RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - \ && echo "deb https://download.docker.com/linux/ubuntu focal stable" \ > /etc/apt/sources.list.d/docker.list \ && apt-get update \ && DOCKER_VERSION=$(apt-cache madison docker-ce | awk '{print $3}' | grep -m1 "$DOCKER_VERSION") \ && apt-get -y install docker-ce="$DOCKER_VERSION" \ && apt-mark hold docker-ce # Install kubeadm, kubelet and kubectl # https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl ARG KUBE_VERSION=1.20 RUN curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - \ && echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" \ > /etc/apt/sources.list.d/kubernetes.list \ && apt-get update \ && KUBE_VERSION=$(apt-cache madison kubelet | awk '{print $3}' | grep -m1 "$KUBE_VERSION") \ && apt-get -y install kubelet=$KUBE_VERSION kubeadm=$KUBE_VERSION kubectl=$KUBE_VERSION cri-tools \ && apt-mark hold kubelet kubeadm kubectl # Disable automatic updates RUN rm -f /etc/apt/apt.conf.d/20auto-upgrades # Disable apparmor profiles RUN find /etc/apparmor.d \ -maxdepth 1 \ -type f \ -name "sbin.*" \ -o -name "usr.*" \ -exec ln -sf "{}" /etc/apparmor.d/disable/ \; # Setup locales RUN printf '%s\n' \ 'LANG=en_US.UTF-8' \ 'LC_TIME=en_DK.UTF-8' \ 'LC_CTYPE=en_US.UTF-8' \ > /etc/locale.conf \ && locale-gen en_US.UTF-8 en_DK.UTF-8 #------------------------------------------------------------------------------- # Build kernel modules #------------------------------------------------------------------------------- FROM rootfs-pre as modules # Install kernel-headers and dkms RUN apt-get update \ && KERNEL_VERSION="$(ls -1 /lib/modules/ | tail -n1)" \ && apt-get -y install "linux-headers-${KERNEL_VERSION}" dkms \ && apt-get clean # Install DRBD modules RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CC1B5A793C04BB3905AD837734893610CEAA9512 \ && echo "deb http://ppa.launchpad.net/linbit/linbit-drbd9-stack/ubuntu focal main" \ > /etc/apt/sources.list.d/linbit.list \ && apt-get update \ && apt-get -y install drbd-dkms #------------------------------------------------------------------------------- # Build rootfs image #------------------------------------------------------------------------------- FROM rootfs-pre as rootfs # Copy kernel modules COPY --from=modules /lib/modules/ /lib/modules/ # Generate initramfs with new modules RUN update-initramfs -u # Generate motd COPY motd /etc/motd RUN sed -i "s/\${VERSION}/${VERSION}/" /etc/motd # Generate image ENV OMIT_FUNCTIONS="remove_users" RUN ltsp image -I / #------------------------------------------------------------------------------- # Build dnsmasq with tftp single port support #------------------------------------------------------------------------------- FROM ltsp as builder # Common build-dependencies RUN apt-get -y update \ && apt-get -y install \ git \ build-essential \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* \ # Build dnsmasq ARG DNSMAQ_VERSION=2.81-12-g619000a RUN git clone git://thekelleys.org.uk/dnsmasq.git \ && cd dnsmasq/ \ && git checkout ${DNSMAQ_VERSION} \ && make #------------------------------------------------------------------------------- # LTSP-Server #------------------------------------------------------------------------------- FROM ltsp RUN apt-get -y update \ && apt-get -y install \ grub-pc-bin \ grub-efi-amd64-bin \ inotify-tools \ nginx \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # Generate nginx config RUN ltsp http -I COPY --from=builder /dnsmasq/src/dnsmasq /usr/sbin/dnsmasq COPY --from=rootfs /srv/ltsp/images /srv/ltsp/images COPY --from=rootfs /srv/tftp/ltsp /srv/tftp/ltsp Но проблема в том, что если у нас есть вебхук, то он, как правило, запущен в виде стандартного пода с сервисом в нашем кластере. И когда apiserver попробует к нему достучаться, то у него ничего не получится — потому что он будет пытаться обратиться к in-cluster сервису по имени webhook.namespace.svc: И здесь нам на помощь приходит Konnectivity — хитрый прокси-сервер созданный специально для Kubernetes. Он деплоится в виде сервера рядом с apiserver. А Konnectivity-agent деплоится уже непосредственно в кластере, в который вы хотите ходить, также в нескольких репликах. Агент устанавливает подключение к серверу и позволяет apiserver наладить стабильный канал, чтобы тот смог ходить через него и имел возможность обращаться со всеми вебхуками и всеми kubelet’ам в кластере. Таким образом теперь всё общение с кластером будет происходить через Konnectivity-server: Наши планыКонечно, на этом этапе мы останавливаться не собираемся. Мне достаточно часто пишут заинтересованные в проекте люди. И если наберется критическая масса, я надеюсь переместить Kubernetes-in-Kubernetes под крыло Kubernetes-SIGs, представив его в виде официального Kubernetes Helm-чарта. И, возможно, так мы соберем ещё большее комьюнити. Также я подумываю сделать интеграцию с Machine Controller Manager, что позволило бы создавать worker’ы, не только на физических серверах, а например создавать виртуалки используя kubevirt и запускать их в том же Kubernetes-кластере. Им кстати, можно также создавать виртуалки в облаках, имея control-plane, задеплоенный у себя локально. Также я рассматриваю вариант интеграции с Cluster-API, чтобы можно было создавать физические кластера Kubefarm прямо через окружение Kubernetes. Но на данный момент я не до конца уверен в этой идее. Если у вас есть мысли на этот счет, с радостью их выслушаю. В этом году DevOpsConf пройдёт в гибридном формате. Это значит, что и онлайн- и офлайн-участники смогут общаться с партнёрами конференции, задавать вопросы спикерам и участвовать в активностях в зоне выставки.Бронируйте билеты и присоединяйтесь к сообществу фанатов DevOps-подхода! Расписание здесь.
=========== Источник: habr.com =========== Похожие новости:
Блог компании Конференции Олега Бунина (Онтико) ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_*nix, #_devops, #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:40
Часовой пояс: UTC + 5