Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж

в 11:10, , рубрики: devops, k8s, kubernetes, системное администрирование, челлендж

Привет! Я Александр Хренников — руководитель DevOps-юнита в KTS. Первый коммит в репозиторий kubernetes был сделан 10 лет назад, 6 июня 2014 года. За это время kubernetes прошёл большой путь и стал самым популярным средством оркестрации контейнеров. 

Предлагаю вам посмотреть, каким он был в то время, и попробовать запустить в нём приложение самостоятельно. 

Заодно приглашаем принять участие в челлендже по запуску kubernetes из самого первого коммита. Это продолжение нашего совместного челленджа c Yandex Cloud на KuberConf / 24, где мы запускали приложение без ошибок на инфраструктуре облака.

Если собирать компоненты с нуля желания нет, а запустить их хочется уже сейчас, участвуйте в Kube01 Challenge по запуску k8s v.0.1 на инфраструктуре Yandex Cloud. Принять участие и выиграть мерч с Котзиллой можно по ссылке.

Код первого коммита всё ещё доступен в репозитории kubernetes.

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 1

Как собрать kubernetes v0.1

Для запуска нам потребуется машина  ̶в̶р̶е̶м̶е̶н̶и̶  под управлением Ubuntu 14.04. Эта версия ОС нужна чтобы запустить все зависимости которые необходимы для сборки kubernetes. 

На машине установим необходимые пакеты:

apt update

apt install git iptables curl apache2-utils

Добудем компилятор Go нужной версии:

wget https://dl.google.com/go/go1.2.2.linux-amd64.tar.gz

tar -C /usr/local -xzf go1.2.2.linux-amd64.tar.gz

export PATH=$PATH:/usr/local/go/bin 

export GOPATH=$HOME/go 

export PATH=$PATH:$GOPATH/bin

Теперь нужно скачать репозиторий kubernetes и перейти в первый коммит:

cd /root

git clone https://github.com/kubernetes/kubernetes.git

cd kubernetes

git log --reverse

git commit 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56

git checkout 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56

И, наконец собрать kubernetes:

cd /root/kubernetes/src/scripts

./build-go.sh

cd /root/kubernetes/target

etcd

etcd с самого начала использовался для работы kubernetes поэтому стоит его установить:

wget https://github.com/etcd-io/etcd/releases/download/v2.3.8/etcd-v2.3.8-linux-amd64.tar.gz

tar xzvf etcd-v2.3.8-linux-amd64.tar.gz

cd etcd-v2.3.8-linux-amd64


cp etcd /usr/local/bin/ 

cp etcdctl /usr/local/bin/

Сборка Docker

Естественно для запуска kubernetes необходимо использовать и docker той самой версии, которая была в то время. Добудем её из архива. 

git clone https://github.com/docker-archive/engine.git

cd engine

git checkout v1.0.0

Теперь придётся немного пострадать и установить все необходимые для сборки зависимости. 

Найти их можно в Dockerfile. Нужно нужно поставить все до 62 строки. Из того, что может вызвать сложности, lvm можно получить вот в этом репозитории.

В качестве go можно использовать go версии 1.2.2, на сборку минорная версия не влияет.

Когда установлены зависимости — можно перейти к сборке:

AUTO_GOPATH=1 ./hack/make.sh binary

Собранное приложение можно будет найти в папке: ./bundles/1.0.0/binary/

Примечание, вместо приведённого тут архивного репозитория docker можно использовать репозиторий Moby код с тегом v1.0.0 в них идентичен, т.к. написан до разделения.  

Moby — это «фреймворк», который пришёл на смену монолитному репозиторию docker и позволяющий собирать самому решения контейнеризации на основе docker. По сути и все текущие продукты docker собираются на его основе. Подробнее об этом — здесь.

Компоненты

Компонентов в первой версии kubernetes было значительно меньше, но они сохранились до наших дней. Стоит заметить, что среди компонентов отсутствует auth, а это значит, что api первой версии не был защищён ничем, и для этих целей стоит использовать nginx + basic auth, если есть желание выставить его в большой интернет. 

  • apiserver - отвечал за управление кластером, в том числе опрашивал kubelet-ы через rest-интерфейс о запущенных контейнерах;

  • cloudcfg  (впоследствии kubectl) — позволял обращаться к api из консоли.

  • controller-manager — приводил количество запущенных task-ов к требуемым;

  • kubelet — как и сейчас — запускал контейнеры по описанной конфигурации и отдавал статус контейнеров по http;

  • proxy — простой прокси-сервер, написанный на go и умеющий распределять запросы по эндпоинтам согласно логике RoundRobin.

В первых версиях kubernetes etcd использовался не только как хранилище конфигурации, но и как основное средство коммуникации между компонентами. Все компоненты регистрировались в etcd, после чего apiserver ходил и самостоятельно обращался к kubelet-ам. По этой причине в первых версиях было сильно ограничено количество нод кластера, apiserver просто не успевал обратиться ко всем нодам.  

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 2

Абстракции

Рассмотрим основные абстракции, которые присутствовали в системе в то время. Список весьма ограничен и сильно отличается от того, к чему мы привыкли сейчас. Впрочем, этого набора вполне хватало для запуска контейнеров и минимального управления их работой.

Task 

В самом начале в kubernetes не существовало привычных нам pod-ов и основной единицей запущенного приложения был task. Вот пример его описания:

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 3

Фактически task содержал в себе описания параметров запуска контейнера и список лейблов, которые должны быть ему присвоены. Вот тут доступно полное описание схемы.

ReplicationController

Прообраз современного ReplicaSet оперировал шаблонами task-ов и описывал необходимый набор экземпляров для запуска в облаке:

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 4

Здесь доступно полное описание схемы.

Service

Единственная сущность, которая сохранилась в kubernetes до наших дней, хотя и обросла большим количеством различных вариантов и параметров:

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 5

Управление

api

Как и сейчас, управление производилось через api-сервер, правда в составе методов были только соответствующие приведённым выше сущностям /tasks /replicationControllers /services. Подробнее можно прочитать по ссылке.

cloudcfg

Привычного нам kubectl не существовало, вместо него использовался cloudcfg, передававший запросы на api. Для удобства использования он был завёрнут в cloudcfg.sh который добавлял в запрос адрес KUBE_MASTER:

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 6

Пример использования cloudcfg напрямую:

Назад в прошлое: запускаем k8s v.0.1 из 2014 и анонсируем челлендж - 7

Анонс челленджа

Мы с вами вернулись в прошлое и собрали первую версию Kubernetes, чтобы своими глазами увидеть, как всё начиналось. Теперь у вас есть всё, чтобы запустить kubernetes и выиграть футболку с Котзиллой в нашем челлендже. Чтобы участвовать, переходите в наш бот.

Автор: demonight

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js