Что такое Kubernetes и каковы его основные компоненты?

А, Кубернетис, говоришь? Ну это ж, блядь, такая штука, чтобы твои контейнеры, эти, как их... микросервисы, не разбежались, сука, кто куда, а маршировали строем, как на параде! Представь: у тебя дохуя маленьких коробочек-приложений, и каждая орет "я главная!", "мне больше памяти!", "я упала, поднимите!". Так вот, кубер — это такой злой, но справедливый надзиратель с дубинкой, который всех этих мартышлюшек строит в шеренгу и заставляет работать.

Архитектура, или кто тут главный на районе:

• Кластер (Cluster): Это типа весь твой дата-центр в миниатюре. Куча серверов, связанных в одну банду.
• Плоскость управления (Control Plane / Master Node): Это, блядь, главный мозг, штаб. Сидит себе такой, курит бамбук, и думает: "Ага, тут поду упала, тут масштабироваться надо". Он всем заправляет. Босс.
• Рабочая нода (Worker Node): Это уже рабы, работяги. Те самые сервера, которые реально пашут, таская на своей горбу твои контейнеры. Получают пинки под жопу от мастера и бегут работать.

Ключевые фигуры, без которых нихуя не работает:

• Под (Pod): Самая мелкая, но важная сошка. Это как капсула, в которой сидит одно или несколько приложений, обнявшись. Представь: один под — это как квартира, а контейнеры в нём — это соседи по коммуналке, которые делят одну сеть и дисковое пространство. Иногда орут друг на друга.
• Деплоймент (Deployment): А вот это уже, сука, крутой менеджер среднего звена. Ты ему говоришь: "Хочу три одинаковых пода, и чтобы если один сдох — сразу новый вырос, как хвост у ящерицы!". Он кивает и делает. Ещё он умеет аккуратно обновлять всё это хозяйство, не выключая свет во всём доме (rolling update). А если новое обновление — говно, он может всё откатить назад, мать его.
• Сервис (Service): Это, блядь, лицо компании, секретарь на ресепшене. Поды рождаются и умирают, у них адреса меняются чаще, чем трусы, а сервис — это стабильная вывеска, константа. К нему обращаются клиенты, а он уже внутри, как хитрая жопа, распределяет трафик между всеми подами, которые в этот момент живы. Балансировщик нагрузки, короче.

# Смотри, как это примерно выглядит в коде. Это как оставить записку Куберу.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Название, чтоб не забыть
spec:
  replicas: 3 # Хочу ТРИ копии, блядь! Не две и не четыре!
  selector:
    matchLabels:
      app: nginx # Ищу всех, кто с биркой "nginx"
  template: # А вот шаблон того, кого буду создавать
    metadata:
      labels:
        app: nginx # Вешаю бирку "nginx"
    spec:
      containers:
      - name: nginx # Внутри пода будет контейнер...
        image: nginx:1.14.2 # ...с таким вот образом (картинкой, прости господи)
        ports:
        - containerPort: 80 # И он будет слушать на 80-м порту

И нахуй это всё надо? А вот нахуй:

• Масштабирование горизонтальное: Трафик пиздец как нарос? Не вопрос. В конфиге меняешь цифру replicas с 3 на 30, и кубер, ёпта, как сумасшедший, начнёт плодить новые копии твоего приложения. Волшебство, блядь!
• Самовосстановление: Сервер взял и накрылся медным тазом? Или контейнер сдох просто от скуки? Кубер это увидит, хлопнет себя по лбу, и запустит всё заново на другой ноде. Ты даже и не узнаешь, что был пожар.
• Обновления и откаты без боли: Раньше, чтобы новую версию залить, надо было ночью всем сервис останавливать, молиться и делать бекап. Теперь — фокус-покус, rolling update. Пользователи даже не почувствуют, что их, по сути, пересадили с одной лошади на другую на полном скаку.
• Переносимость ебать: Написал конфиги — и они, сука, будут работать и у себя в подвале, и в облаке Amazon, и у Google. Одна и та же песня. Не привязываешься к продавцу, как сосалка.

Короче, если коротко — это чтобы не ебать себе мозг вручную, а поручить всю рутину этой умной системе. Правда, иногда она сама такую сложность создаст, что волнение ебать... Но это уже другая история.