Сегодня я хочу рассказать о пакете MicroK8s, который без преувеличения позволяет развернуть Kubernetes локально за несколько минут, и начать разработку. Не требуется даже предустановленных Docker и Kubernetes, т.к. все включено. В предлагаемом Вам уроке будет рассмотрен деплой приложения Django в локальной среде Kubernetes.
В качестве источника я шел вслед за серией статей Mark Gituma, в которых описана аналогичная работа, но только с Minikube, а не с MicroK8s.
Все же есть одно требование, которое необходимо удовлетворить до начала работы. У Вас должен быть установлен Snap, что в свою очередь означает, что у Вас должен быть установлен Linux.
Установка MicroK8s описана в руководстве на сайте. Впрочем, это всего одна строчка:
sudo snap install microk8s --classic
Далее, возможно, будет необходимо стартовать среду:
sudo microk8s.start
Далее необходимо активизировать расширения. Полный список расширений можно получить командой
microk8s.enable --help
: dashboard, dns, gpu, ingress, istio, metrics-server, registry, storage. Сразу можно активизировать все, кроме gpu и istio, т.к. первое из них требует предустаноленного драйвера, а второе существенно апгрейдит среду и (лично у меня на слабом десктопе) сильно грузит систему.microk8s.enable dashboard dns ingress metrics-server registry storage
Как Вы уже сейчас можете заключить по списку расширений, у Вас будет доступ ко многим сервисам, в том числе к dashboard и метрикам.
Создадим Dockerfile для создания образа:
FROM python:3-slim
LABEL maintainer="mark.gituma@gmail.com"
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
RUN django-admin startproject mysite /app
EXPOSE 8000
STOPSIGNAL SIGINT
ENTRYPOINT ["python", "manage.py"]
CMD ["runserver", "0.0.0.0:8000"]
и файл с необходимыми зависимостями requirements.txt:
celery==4.1.0
Django==2.0
kombu==4.1.0
Соберем образ. Для этого не нужен предустановленный Docker, т.к. он поставляется c MicroK8s:
microk8s.docker build django -t apapacy/tut-django:1.0.0
Если Вы собираете образ раннее установенным докером, возможно Вам будет недостаточно просто собрать образ, а еще дополнительно отправить в локальный реестр, который также поставляется с MicroK8s, и работет на порту 32000:
microk8s.docker tag apapacy/tut-django:1.0.0 localhost:32000/apapacy/tut-django:1.0.0
microk8s.docker push localhost:32000/apapacy/tut-django:1.0.0
Скорее всего этот шаг будет не нужен, но для полноты я указал на него, и заодно обратил Ваше внимание, что у Вас есть локальный реестр докера.
Базовым строительным блоком Kubernetes является Pod (Под), в котором работает контенйер (чаще всего один но может быть и несколько). Поды могут создаваться разными средствами. Но нас сегодня интересует Deployment (Деплоймент). Деплоймент описывает шаблон по которому создаются Поды. Деплоймент определяется при помощи файлов конфигрураций в формате yml. В конфигурации Деплоймента Вы указываете количество реплик Пода и образ, из которого этот Под и его реплики будут собираться, а также порт (порт 8000 на котором работет Django из Dockerfile — никакой магии):
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: django
labels:
app: django
spec:
replicas: 2
selector:
matchLabels:
pod: django-container
template:
metadata:
labels:
pod: django-container
spec:
containers:
- name: django-web
image: localhost:32000/apapacy/tut-django:1.0.0
ports:
- containerPort: 8000
Депоймент загружается в среду командой:
microk8s.kubectl apply -f config/deployment.yml
Параллельно Вы можете запустить команду, которая будет мониторить происходящие при деплойменте действия:
watch microk8s.kubectl get all
Теперь у Вас есть несколько Подов с приложениями Django, к которым нет доступа. Для того, чтобы Поды могли общаться между собой и с внешним миром, существует еще одна абстракция — это Сервис. Сервис, как и Деплоймент, определяется файлом конфигурации:
kind: Service
apiVersion: v1
metadata:
name: django-service
spec:
selector:
pod: django-container
ports:
- protocol: TCP
port: 8000
# targetPort: 8001
type: ClusterIP
# type: NodePort
Селектор
pod: django-container
определяет, какой именно Деплоймент будет обслуживаться Сервисом (имя селектора «pod» не является предопределенным — это всего лишь метка котороая должна совпасть). Загружается сервис аналогично Деплойменту:microk8s.kubectl apply -f config/service.yml
После загрузки, к Сервису можно обращаться по внутреннему сетевому адресу. Если выполнить команду
microk8s.kubectl get all
, то можно увидеть этот адрес:service/django-service ClusterIP 10.152.183.156 none 8000/TCP 3h33m
Выполнив команду curl (или открыв браузер) мы получим приветсвенную страничку Django:
curl 10.152.183.156:8000
В конфигурации Сервиса есть две закомментированные строчки. Если их раскомментировать, то сервис дополнительно будет доступен из внешней сети по случайному порту в диапазоне от 32000 и выше.
Для того чтобы получить постоянный адрес для Сервиса, по котрому можно будет обращаться из вешней сети, в MicroK8s предлагается на выбор два варианта 1) ingress и 2) istio. Проще всего реализовать при помощи ingress. Если еще не активизирован, то нужно активизировать компнент ingress:
microk8s.enable ingress
После этого можно убедиться, что данный компонент установлен и работает, выполнив команду
microk8s.kubectl get all
. В списке приложений и сервисов должно появиться несколько записей с именем default-http-backend
. В частности, должен появиться сервис, работающий на порту 80:service/default-http-backend ClusterIP 10.152.183.42 none 80/TCP 179m
Имя default-http-backend — предопределенное имя в MicroK8s. Именно по этому имени необходимо ссылаться на этот сервис в конфигурациях ingress.
Конфигруации ingress напоимнают конфигруации веб-сервера или прокси-сервера, и где-то там внутри системы, ими и являются. Поэтому в них присутсвуют хосты, пути и порты — все атрибуты, которые хорошо знакомы:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: tut-django
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
backend:
serviceName: default-http-backend
servicePort: 80
rules:
- host: localhost
http:
paths:
- path: /django
backend:
serviceName: django-service
servicePort: 8000
Загружается конфигруация ingress командой:
microk8s.kubectl apply -f config/ingress.yml
После чего, приветственная страница Django будет доступна по адресу localhost/django
На этом на сегодня все.
Полезные ссылки:
1. github.com/apapacy/microk8s-tut
2. medium.com/@markgituma/kubernetes-local-to-production-with-django-2-docker-and-minikube-ba843d858817
apapacy@gmail.com
10 февраля 2019 года
Комментарии (11)
DukeKan
10.02.2019 22:14— Все же есть одно требование, которое необходимо удовлетворить до начала работы.
Переводчики… Переводчики никогда не меняютсяapapacy Автор
10.02.2019 22:34Согласен, профессия переводчика весьма древняя. Хотя, если говорить об этой заметке то это не перевод. Я в качестве отправной точки использовал статью на которую дал ссылку. Но к я следовал только примерам из этой статьи но не тексту.
outcoldman
10.02.2019 22:21> Но, все же, о Minikube нельзя сказать, что с помощью этой утилиты можно за несколько минут развернуть среду Kubernetes.
Не очень понятна эта фраза. Запустить minikube — это minikube start. Занимает несколько минут.apapacy Автор
10.02.2019 22:32До того как запустить minikube его нужно установить. Мне для этого пришлось устанавивать kvm например, на ubuntu. В случае с MicroK8s — это действительно несколько секунд на установку и среда готова. Правда нехватает немного документациии статей, что конечно немного замедляет процесс освоения работы с MicroK8s.
whitehat
12.02.2019 19:22+1в microk8s мне не понравилось слишком тесная интеграция с хостовой машиной. в отличии от minikube, если в deployment написано примонтировать /var хостовой машины в под — он это и сделает. Поэтому мне больше по душе rancher RKE, который мало того что позволяет запускать куб без виртуализации, но ещё и может эмулировать несколько хостов (docker in docker). При этом куб изолирован от хостовой машины
SimSonic
12.02.2019 20:19Сегодня практически целый день убил на разворачивание кластера k8s на виртуалке с fedora atomic host. В целом поставить удалось, поды вручную запускаются, но пока встал на паузу с тем, что gitlab отказывается ставить на него helm tiller (500 :<).
gecube
12.02.2019 20:20М-м-м. Устанавливали через microk8s? Почему не опешнифт сразу (у него хотя бы установка через вменяемые плейбуки). Ресурсов сколько? Почему fedora atomic, а не coreos container linux?
SimSonic
12.02.2019 21:34Успел попробовать и microk8s, но с ним почему-то постоянно все сервисы подписали. Очень странно. Потом посмотрел в сторону mini kube, но заметил его предупреждение о vmx|svm (виртуалка на qemu, флаги не показала, решил не рисковать). Честно все это админство не моя проф.ориентация, но потрогать хочется. Про coreos с утра ещё не знал, сейчас покурил мануалы, выглядит интересно, возможно попробую. Моя нынешняя цель — одна система мастер/нода с 3 Гб для сборки проекта, мб и как демо стенд.
gecube
После snap можно уже не читать.
Нужно больше возможностей гонять куски кубов и шифтов на локальной машине. Но в зависимости от потребностей понадобятся разные решения. Я лично остановился на https://github.com/pyToshka/openshift-vagrant
как на наиболее полноценном решении. Ах, да, я ещё на маке и поэтому тащить ещё два слоя виртуализации не хочется. И, да, опеншифт даже для локальной разработки прикольнее, чем миникьюбы, даже хотя и потребление ресурсов больше, но оно все равно в пределах допустимого
apapacy Автор
Учел Ваше замечание. Упоминание про Snap и Linux поместил выше cat*, чтобы не нужно просматирвать то что по катом. Кстати я упоминаю Minikube, но сама заметка о MicroK8s. Ее раработчики (хотя с этим можно поспорить) утверждают что в отличие от Minikube — MicroK8s можно использовать не только для разработки но и для управления небольшими проектами. Все это нужно еще конечно проверять. Но во всяком случае это более привлекатеьно чем выкатывать на прод мелкие проекты на docker-compose как это сейчас к сожалению довольно распространено.
gecube
Спасибо за комментарий. Полностью с Вами согласен, тем более в ключе того, что docker-compose — для тестов и отладки, а не для прода (хотя многие его тащат и туда).
Касательно того, почему я так сагрился на snap — есть причины. Начиная от того, что коллега установил docker через него, и мы потом не могли его (т.е. докер-демон) нормально настроить. И кончая тем, что snap во многих дистрибутивах — лишняя сущность (я сам адепт OpenSUSE на рабочем десктопе). Если кто-то хочет сделать крутую вещь под Linux и максимально универсальную, то должен поддержать разные сценарии установки. А идеальный вариант — сделать штуку, которая будет одинаково работать и под mac (все больше разработчиков начинают работать на них), и под win (докер уже есть и там, подсистема линукс там тоже есть...)