История изменений
Исправление
vertexua,
(текущая версия)
:
узел кластера может быть либо мастером, либо воркером. как объединить обе роли в одном сервере?
Можно сделать мастером, а потом убрать --register-schedulable=false. В гайдах он обычно стоит у мастера, но если его убрать или лучше явно поставить в true, то контенеры начнут запускаться на мастере тоже.
как прокидывать айпиадреса наружу, чтобы был доступ к сервисам kubernetes?
Сначала нужно прокинуть порт из контейнера. Потом нужно зарегистрировать Service обьект в Kubernetes. А вот теперь два варианта.
Если нужно прокинуть какой-то TCP (обычно не HTTP), то можно в обьекте ports у сервиса использовать поле nodePort. Например если у тебя обьект порт есть в сервисе, и у него есть следующие свойства, то вот что это будет значить
- port: 5269 // при присоединении из внутренней (flannel) сети к этому сервису, сервис будет доступен по этому порту
- targetPort: 5269 // этот сервис редиректит на этот порт в pods
- nodePort: 5269 // при присоединении из внешней сети к ЛЮБОМУ узлу кубернетеса по этому порту, будет происходить редирект на этот порт этого сервиса.
Второй вариант - когда у тебя HTTP. Тогда смотри Ingress ресурсы. Тогда nodePort для 80 и 443 регистрируется раз и навсегда для самого ингресс-контроллера, а он уже будет обеспечивать например виртуальный хостинг для твоих сервисов. Тоесть если у тебя кубернетес кластер (любое подмножество узлов) доступен по example.com, то через ингресс его можно научить редиректить на разные сервисы если кто-то зайдет на foo.example.com и bar.example.com. Безопасность может быть настроена раз и навсегда для всех этих доменов на самом ингрессе, например авторизация. HTTPS делается тоже на ингрессе автоматически для всех сервисов через Let's Encrypt если установить в кластер Kubernetes Lego.
Исправление
vertexua,
:
узел кластера может быть либо мастером, либо воркером. как объединить обе роли в одном сервере?
Можно сделать мастером, а потом убрать --register-schedulable=false. В гайдах он обычно стоит у мастера, но если его убрать или лучше явно поставить в true, то контенеры начнут запускаться на мастере тоже.
как прокидывать айпиадреса наружу, чтобы был доступ к сервисам kubernetes?
Сначала нужно прокинуть порт из контейнера. Потом нужно зарегистрировать Service обьект в Kubernetes. А вот теперь два варианта.
Если нужно прокинуть какой-то TCP (обычно не HTTP), то можно в обьекте ports у сервиса использовать поле nodePort. Например если у тебя обьект порт есть в сервисе, и у него есть следующие свойства, то вот что это будет значить
- port: 5269 // при присоединении из внутренней (flannel) сети к этому сервису, сервис будет доступен по этому порту
- targetPort: 5269 // этот сервис редиректит на этот порт в pods
- nodePort: 5269 // при присоединении из внешней сети к ЛЮБОМУ узлу кубернетеса по этому порту, будет происходить редирект на этот порт этого сервиса.
Второй вариант - когда у тебя HTTP. Тогда смотри Ingress ресурсы. Тогда nodePort для 80 и 443 регистрируется раз и навсегда для самого ингресс-контроллера, а он уже будет обеспечивать например виртуальный хостинг для твоих сервисов. Тоесть если у тебя кубернетес кластер (любое подмножество узлов) доступно по example.com, то через ингресс его можно научить редиректить на разные сервисы если кто-то зайдет на foo.example.com и bar.example.com. Безопасность может быть настроена раз и навсегда для всех этих доменов на самом ингрессе, например авторизация. HTTPS делается тоже на ингрессе автоматически для всех сервисов через Let's Encrypt если установить в кластер Kubernetes Lego.
Исходная версия
vertexua,
:
узел кластера может быть либо мастером, либо воркером. как объединить обе роли в одном сервере?
Можно сделать мастером, а потом убрать --register-schedulable=false. В гайдах он обычно стоит у мастера, но если его убрать или лучше явно поставить в true, то контенеры начнут запускаться на мастере тоже.
как прокидывать айпиадреса наружу, чтобы был доступ к сервисам kubernetes?
Сначала нужно прокинуть порт из контейнера. Потом нужно зарегистрировать Service обьект в Kubernetes. А вот теперь два варианта.
Если нужно прокинуть какой-то TCP (обычно не HTTP), то можно в обьекте ports у сервиса использовать поле nodePort. Например если у тебя обьект порт есть в сервисе, и у него есть следующие свойства, то вот что это будет значить
port: 5269 // при присоединении из внутренней (flannel) сети к этому сервису, сервис будет доступен по этому порту targetPort: 5269 // этот сервис редиректит на этот порт в pods nodePort: 5269 // при присоединении из внешней сети к ЛЮБОМУ узлу кубернетеса по этому порту, будет происходить редирект на этот порт этого сервиса.
Второй вариант - когда у тебя HTTP. Тогда смотри Ingress ресурсы. Тогда nodePort для 80 и 443 регистрируется раз и навсегда для самого ингресс-контроллера, а он уже будет обеспечивать например виртуальный хостинг для твоих сервисов. Тоесть если у тебя кубернетес кластер (любое подмножество узлов) доступно по example.com, то через ингресс его можно научить редиректить на разные сервисы если кто-то зайдет на foo.example.com и bar.example.com. Безопасность может быть настроена раз и навсегда для всех этих доменов на самом ингрессе, например авторизация. HTTPS делается тоже на ингрессе автоматически для всех сервисов через Let's Encrypt если установить в кластер Kubernetes Lego.