LINUX.ORG.RU

История изменений

Исправление 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.