Comments 16
Из собственного опыта:
1. Minikube — внезапно проблемное нечто. Кроме внезапных и малопонятных глюков, как например в статье, если использовать его в виртуалке, то можно обнаружить, что ФС полностью очищается при перезапуске. И если вы решите поставить в эту же виртуалку что-то «внешнее» — будете страдать.

2. Почему-то во всех гайдах про LoadBalancer забывают одну важную деталь. Если кто-то решит использовать такой yaml на реальном проекте, он может обнаружить, что при пересоздании LoadBalancer (не важно по каким причинам) IP поменяется. А все потому что надо в GKE отдельно арендовать IP и к нему привязывать LoadBalancer. Это просто, но надо знать заранее.

1 характерно и для управляемых кластеров, даже если дали права на саму ноду. Там какой-нибудь паппет может по крону все очишать. Так что близко к реальности.

Согласен. Но для локальной разработки — неудобно. У меня в итоге обычная виртуалка крутится, на которой обычный k8s поднят. Так проще.
а какой вообще самый простой способ экспериментировать с k8s на одной ноде? (ну то есть на одной виртуалке или 1vps)

Тут спорно. Удобно, конечно локально делать всё, что хочешь, но потом это рано или поздно приводит к ошибкам при "у меня всё работает" и необходимости дебажить и фиксить хорошо если на тестовом окружении удаленном, а не на проде.

Если вы подскажете способ очень быстрой (как у шареных папок в виртуалбоксе) синхронизации файлов исходников с удаленным k8s, буду благодарен.

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

В реальности же практически не сталкиваюсь с проблемами «у меня все работает» при условии использовании одного и того же дистрибутива. Плюс стараюсь делать минимальные отличия дев/прод. Т.е. это буквально выделение ресурсов, реплики и докер-образ с вшитыми исходниками.

UPD. Это накладывает некоторые технические особенности. Например, я работаю на ноуте с 32Гб озу, чтобы все это влазило локально. Кто-то скажет, что это дофига.
Либо я не понял что куда, либо это не то.
Проще уж виртуалку поднять, чем разворачивать часть там, часть тут.

Оно подставляет прокси на локальную машину вместо целевого контейнера в любом кластере (при наличии прав, конечно), хоть локально, хоть в виртуалке, хоть в каком-нибудь клауде на продакшене. Локально же поднимается произвольный докер-контейнер (есть ещё какие-то варианты, но не вникал) с монтированием произвольных каталогов.


То есть это синхронизация файлов с удаленным кластеров, а подмена удаленных файлов и процессов в контейнере кластера своими. Единственный вариант, в котором без танцев с бубнами у меня заработали все основные функции вебпака с конфигом от create-react-app, включая горячую перезагрузку при изменении исходников.

Значит я все правильно понял. По мне так локальная виртуалка удобнее. По крайней мере в моем случае. Плюс это бесплатно — не нужно держать отдельную дев-машину (мне например надо 16 озу + нормальный проц).

Под какие-то другие проекты, возможно, будет удобнее. Приму на вооружение, спасибо.

Спасибо за комментарий. Согласен, этот момент с LoadBalancer'ом стоит упомянуть. Дополнил статью

Почему-то во всех гайдах про LoadBalancer забывают одну важную деталь.

Поэтому все и пользуются, по возможности, ингрессом.

Рассмотрим некоторые объекты Kubernetes

Новичкам будет удобно, если вы сразу определите горизонты этой кухни, куда копать дальше. Все эти ресурсы разные у всех провайдеров (у GKE — одни, у EKS — другие, у OpenShift — третьи):


kubectl api-resources

И можно создавать свои ресурсы (CRD).


ConfigMap — можно привести пример, как сразу конфиги туда писать. Он не только для переменных. Например, человек хочет конфиг для Томката. Чтобы менять, не пересобирая имэдж, он просто меняет сам конфиг. Собственно, в этом и смысл конфигов — запускать по разному одну и туже сущность.
Этот конфиг (по сути файл) монтируется прямо на диск контейнера.


Так лучше не делать:


- port: 8080

Лучше с именем. Под будущий мониториг, который будет искать название в kubectl get ep:


- name: http
  port: 8080

И последнее замечание по поводу деплоймента — все отлично сработает, пока репо в открытом доступе. Если нет, то надо скормить Кубернетесу imagePullSecrets.

Only those users with full accounts are able to leave comments. Log in, please.