Kubernetes - это механизм оркестрации контейнеров, предназначенный для размещения контейнерных приложений на наборе узлов, обычно называемом кластером. Эта серия статей с использованием подхода системного моделирования направлена на углубление понимания Kubernetes и лежащих в его основе концепций.
Для этого сообщения в блоге рекомендуется базовое понимание Kubernetes и сетей.
Kubernetes Networking - это основная абстракция Kubernetes. Вкратце, сетевая модель Kubernetes гарантирует, что все модули Kubernetes в кластере могут обмениваться данными. Кроме того, помимо сетевой модели Kubernetes, Kubernetes предоставляет дополнительные базовые абстракции, Kubernetes Services и Kubernetes Ingress.
Используя подход системного моделирования, в этом сообщении блога исследуются сети Kubernetes. Здесь мы разработаем краткую ментальную модель, чтобы рассуждать о коммуникации между контейнерами и контейнерами. В следующих статьях блога будут рассмотрены Kubernetes Services и Kubernetes Ingress.
В этом сообщении в блоге сеть Kubernetes обсуждается на концептуальном уровне, а не на уровне реализации.
1. Как думать о сети
Без сомнения, нетворкинг - обширная и сложная область, требующая многих лет теории и практики, чтобы заявить о себе. Однако здесь мы рассуждаем о сети на концептуальном уровне, пропуская множество деталей, которые были бы необходимы, если бы мы рассуждали на уровне реализации.
Рисунок 1. Идеализированная модель сети.
На рис. 1. сеть показана в виде сетевого графика, который состоит из набора узлов и набора связей между узлами: один узел может обмениваться сообщениями с другим узлом тогда и только тогда, когда существует связь между узлами.
Рисунок 2. Обмен сообщениями, структурный вид
Узел, Источник, обменивается сообщением с другим Узлом, Целевым, помещая сообщение во входную очередь Целевого объекта. Обмен сообщениями представлен событием отправки, Send ● M, наблюдаемым в источнике, и соответствующим событием приема, Recv ● M, наблюдаемым в Target.
Рисунок 3. Обмен сообщениями, поведенческое представление
Узел в сети - это либо процесс, либо коммутатор. Процессы создают и потребляют сообщения. Коммутаторы обрабатывают сообщения в соответствии со своей базой прямой информации (FIB).
Рисунок 4. Прямая информационная база S1 и S2
На рисунке 2 показана база прямой информации коммутаторов S1 и S2. При получении сообщения каждый коммутатор обращается к своей базе переадресации, чтобы определить, следует ли доставить, переслать или отклонить сообщение.
Переключатель сопоставляет заголовок сообщения, то есть исходный адрес, исходный порт, целевой адрес и целевой порт, с его базой переадресации
выполняет связанное действие, отменяя значение по умолчанию.
В следующем сообщении блога Kubernetes Services мы расширим модель коммутатора, чтобы обеспечить преобразование сетевых адресов.
2. Сетевая модель Kubernetes.
Сетевая модель Kubernetes - это описательная сетевая модель, то есть любая сеть, удовлетворяющая спецификации сетевой модели Kubernetes, является сетью Kubernetes. Однако Kubernetes не предписывает, как реализовать сетевую модель. Фактически, сегодня существует множество альтернативных реализаций, называемых сетевыми плагинами. В этом разделе описывается сетевая модель Kubernetes с точки зрения набора ограничений на обмен сообщениями.
2.1. Ограничение ● Сетевые адресные объекты
Сетевая модель Kubernetes определяет три адресных объекта: модули K8s, узлы K8s и службы K8s, где каждый уникальный объект связан с уникальным IP-адресом.
∧ (K8s-Pod(E₁) ∨ K8s-Node(E₁) ∨ K8s-Service(E₁))
∧ (K8s-Pod(E₂) ∨ K8s-Node(E₂) ∨ K8s-Service(E₂)):
addr(E₁, a) ∧ addr(E₂, a)₂
⟺ E₁ = E₂
Однако сетевая модель не делает никаких дополнительных заявлений об этих IP-адресах. Например, сетевая модель Kubernetes не делает никаких дополнительных заявлений о пространствах IP-адресов, из которых взяты эти IP-адреса.
2.2. Ограничение ● Связь между контейнерами
Сетевая модель Kubernetes требует, чтобы контейнер C₁, выполняющийся в контексте Pod P, мог взаимодействовать с любым другим контейнером C, выполняющимся в контексте P через localhost.
K8s-Pod(P) ∧ K8s-Container(C₁, P) ∧ K8s-Container(C₂, P):
open(C₂, p)
⟹
Send(e, C₁, 127.0.0.1, _, 127.0.0.1, p)
⟹
Recv(e, C₂, 127.0.0.1, _, 127.0.0.1, p)
2.3. Ограничение ● От пакета к пакету
Сетевая модель Kubernetes требует, чтобы контейнер C₁, выполняющийся в контексте Pod P, мог связываться с любым другим контейнером C₂, выполняющимся в контексте Pod P₂, через адрес P.
∧ K8s-Pod(P₁) ∧ K8s-Container(C₁, P₁)
∧ K8s-Pod(P₂) ∧ K8s-Container(C2, P₂):
addr(P₁, sa) ∧ addr(P₁, ta) ∧ open(C₂, tp)
⟹
Send(e, C₁, sa, sp, ta, tp)
⟹
Recv(e, C₂, sa, sp, ta, tp)
2.4. Ограничение ● Обработка пакета
Модель Kubernetes Networking требует, чтобы процесс, называемый Daemon D, размещенный на узле N, мог взаимодействовать с любым контейнером C, выполняющимся в контексте Pod P, размещенного на N, через адрес P.
K8s-Node(N) ∧ K8s-Daemon(D) ∧ K8s-Pod(P) ∧ K8s-Container(C, P):
host(N, D) ∧ host(N, P) ∧ addr(P, a) ∧ open(C, p)
⟹
Send(e, D, _, _, a, p)
⟹
Recv(e, C, _, _, a, p)
3. Сети Kubernetes как сетевые графы
В этом разделе описывается сетевая модель Kubernetes с точки зрения сетевого графа Kubernetes, идеализированной модели.
На рисунке 5 показан пример, использованный в этом разделе: Kubernetes Cluster K₁, состоящий из двух узлов. Каждый узел содержит два модуля. Каждый Pod выполняет два контейнера, один из которых прослушивает порт 8080, один контейнер прослушивает порт 9090. Кроме того, на каждом узле размещается один демон.
Рисунок 5. Kubernetes Cluster K₁
Мы можем смоделировать кластерную сеть Kubernetes в виде графика с набором узлов и набором ссылок.
3.1 Узлы
Каждый контейнер C K8s отображается на сетевой процесс C
K8s-Pod(P) ∧ K8s-Container(C, P):
Process(C)
Каждый демон D отображается на сетевой процесс C
K8s-Daemon(D):
Process(D)
Каждый модуль K8s Pod P сопоставляется с сетевым коммутатором P, коммутатор Pod
K8s-Pod(P):
Switch(P)
Каждый узел N K8s соответствует сетевому коммутатору N, коммутатору узла.
K8s-Pod(N):
Switch(N)
3.2 Ссылки
Каждый контейнер C связан со своим Pod Switch P
K8s-Pod(P) ∧ K8s-Container(C, P):
link(C, P)
Каждый демон D связан со своим Node Switch N
K8s-Node(N) ∧ K8s-Daemon(D):
host(N, D)
⟹
link(D, N)
Каждый Pod Switch P связан со своим Node Switch N
K8s-Node(N) ∧ K8s-Pod(P):
host(N, P)
⟹
link(P, N)
Каждый коммутатор Node Switch N связан с каждым другим коммутатором узла N
K8s-Node(N₁) ∧ K8s-Node(N₂):
N₁ ≠ N₂
⟹
link(N₁, N₂)
3.3 Передовая информационная база на переключателе Pod
Рисунок 6. Прямая информационная база P₁
1. Delivery on localhostK8s-Pod(P) ∧ K8s-Container(C, P):
open(C, p)
⟹
[* * 127.0.0.1 p Deliver(C)] in FIB[P]2. Delivery on Pod AddressK8s-Pod(P) ∧ K8s-Container(C, P):
addr(P, a) ∧ open(C, p)
⟹
[* * a p Deliver(C)] in FIB[P]3. Local Forwarding RuleK8s-Node(N) ∧ K8s-Pod(P):
host(N, P)
⟹
[* * * * Forward(N)] in FIB[P]
3.4 Прямая информационная база на коммутаторе узла
Рисунок 7. База прямой информации N₁
1. Node to Pod Forwarding RuleK8s-Node(N) ∧ K8s-Pod(P):
host(N, P) ∧ addr(P, a)
⟹
[* * a * Forward(P)] in FIB[N]2. Node to Node Forwalding RuleK8s-Node(N₁) ∧ K8s-Node(N₂) ∧ K8s-Pod(P):
N₁ ≠ N₂ ∧ host(N₂, P) ∧ addr(P, a)
⟹
[* * a * Forward(N₂)] in FIB[N₁]
Примеры
В этом разделе рассматриваются некоторые примеры и рассказывается о жизни сообщения в кластерной сети Kubernetes K₁.
Контейнер в контейнер
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₁.₂:
C₁.₁ выполняется в контексте Pod P₁
C₁.₂ выполняется в контексте Pod P₁
Рисунок 8. C₁.₁ to C₁.₂ via 127.0.0.1:9090
Связь от модуля к поду, внутриузел
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₃.₁:
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
C₃.₁ выполняется в контексте Pod P₃, который размещен на Node N.
Рисунок 9. C₁.₁ to C₃.₁ via 10.1.1.2:8080
Связь от модуля к поду, межузел
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₂.₁:
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
C₂.₁ выполняется в контексте Pod P₂, который размещен на Node N.
Рисунок 10. C₁.₁ to C₂.₁ via 10.1.2.1:8080
Deamon to Pod Связь
Здесь Daemon D должен взаимодействовать с контейнером C₁.₁:
D₁ размещен на Node N.
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
Рисунок 11. D₁ to C₁.₁ via 10.1.1.1:8080
Заключение
Сетевая модель Kubernetes - это разрешающая сетевая модель, то есть любая сеть, которая удовлетворяет ограничениям сетевой модели Kubernetes, является допустимой сетью Kubernetes.
Сопоставление сетевой модели Kubernetes с сетевым графом позволяет нам рассуждать о сети на концептуальном уровне, пропуская множество деталей, которые были бы необходимы, если бы мы рассуждали на уровне реализации.
В последующих публикациях блога мы будем повторно использовать этот сетевой график для обсуждения Kubernetes Services, Kubernetes Ingress и политик Kubernetes.
Перевод статьи с сайта: https://dominik-tornow.medium.com/
Для этого сообщения в блоге рекомендуется базовое понимание Kubernetes и сетей.
Kubernetes Networking - это основная абстракция Kubernetes. Вкратце, сетевая модель Kubernetes гарантирует, что все модули Kubernetes в кластере могут обмениваться данными. Кроме того, помимо сетевой модели Kubernetes, Kubernetes предоставляет дополнительные базовые абстракции, Kubernetes Services и Kubernetes Ingress.
Используя подход системного моделирования, в этом сообщении блога исследуются сети Kubernetes. Здесь мы разработаем краткую ментальную модель, чтобы рассуждать о коммуникации между контейнерами и контейнерами. В следующих статьях блога будут рассмотрены Kubernetes Services и Kubernetes Ingress.
В этом сообщении в блоге сеть Kubernetes обсуждается на концептуальном уровне, а не на уровне реализации.
1. Как думать о сети
Без сомнения, нетворкинг - обширная и сложная область, требующая многих лет теории и практики, чтобы заявить о себе. Однако здесь мы рассуждаем о сети на концептуальном уровне, пропуская множество деталей, которые были бы необходимы, если бы мы рассуждали на уровне реализации.
Рисунок 1. Идеализированная модель сети.
На рис. 1. сеть показана в виде сетевого графика, который состоит из набора узлов и набора связей между узлами: один узел может обмениваться сообщениями с другим узлом тогда и только тогда, когда существует связь между узлами.
Рисунок 2. Обмен сообщениями, структурный вид
Узел, Источник, обменивается сообщением с другим Узлом, Целевым, помещая сообщение во входную очередь Целевого объекта. Обмен сообщениями представлен событием отправки, Send ● M, наблюдаемым в источнике, и соответствующим событием приема, Recv ● M, наблюдаемым в Target.
Рисунок 3. Обмен сообщениями, поведенческое представление
Узел в сети - это либо процесс, либо коммутатор. Процессы создают и потребляют сообщения. Коммутаторы обрабатывают сообщения в соответствии со своей базой прямой информации (FIB).
Рисунок 4. Прямая информационная база S1 и S2
На рисунке 2 показана база прямой информации коммутаторов S1 и S2. При получении сообщения каждый коммутатор обращается к своей базе переадресации, чтобы определить, следует ли доставить, переслать или отклонить сообщение.
Переключатель сопоставляет заголовок сообщения, то есть исходный адрес, исходный порт, целевой адрес и целевой порт, с его базой переадресации
выполняет связанное действие, отменяя значение по умолчанию.
В следующем сообщении блога Kubernetes Services мы расширим модель коммутатора, чтобы обеспечить преобразование сетевых адресов.
2. Сетевая модель Kubernetes.
Сетевая модель Kubernetes - это описательная сетевая модель, то есть любая сеть, удовлетворяющая спецификации сетевой модели Kubernetes, является сетью Kubernetes. Однако Kubernetes не предписывает, как реализовать сетевую модель. Фактически, сегодня существует множество альтернативных реализаций, называемых сетевыми плагинами. В этом разделе описывается сетевая модель Kubernetes с точки зрения набора ограничений на обмен сообщениями.
2.1. Ограничение ● Сетевые адресные объекты
Сетевая модель Kubernetes определяет три адресных объекта: модули K8s, узлы K8s и службы K8s, где каждый уникальный объект связан с уникальным IP-адресом.
∧ (K8s-Pod(E₁) ∨ K8s-Node(E₁) ∨ K8s-Service(E₁))
∧ (K8s-Pod(E₂) ∨ K8s-Node(E₂) ∨ K8s-Service(E₂)):
addr(E₁, a) ∧ addr(E₂, a)₂
⟺ E₁ = E₂
Однако сетевая модель не делает никаких дополнительных заявлений об этих IP-адресах. Например, сетевая модель Kubernetes не делает никаких дополнительных заявлений о пространствах IP-адресов, из которых взяты эти IP-адреса.
2.2. Ограничение ● Связь между контейнерами
Сетевая модель Kubernetes требует, чтобы контейнер C₁, выполняющийся в контексте Pod P, мог взаимодействовать с любым другим контейнером C, выполняющимся в контексте P через localhost.
K8s-Pod(P) ∧ K8s-Container(C₁, P) ∧ K8s-Container(C₂, P):
open(C₂, p)
⟹
Send(e, C₁, 127.0.0.1, _, 127.0.0.1, p)
⟹
Recv(e, C₂, 127.0.0.1, _, 127.0.0.1, p)
2.3. Ограничение ● От пакета к пакету
Сетевая модель Kubernetes требует, чтобы контейнер C₁, выполняющийся в контексте Pod P, мог связываться с любым другим контейнером C₂, выполняющимся в контексте Pod P₂, через адрес P.
∧ K8s-Pod(P₁) ∧ K8s-Container(C₁, P₁)
∧ K8s-Pod(P₂) ∧ K8s-Container(C2, P₂):
addr(P₁, sa) ∧ addr(P₁, ta) ∧ open(C₂, tp)
⟹
Send(e, C₁, sa, sp, ta, tp)
⟹
Recv(e, C₂, sa, sp, ta, tp)
2.4. Ограничение ● Обработка пакета
Модель Kubernetes Networking требует, чтобы процесс, называемый Daemon D, размещенный на узле N, мог взаимодействовать с любым контейнером C, выполняющимся в контексте Pod P, размещенного на N, через адрес P.
K8s-Node(N) ∧ K8s-Daemon(D) ∧ K8s-Pod(P) ∧ K8s-Container(C, P):
host(N, D) ∧ host(N, P) ∧ addr(P, a) ∧ open(C, p)
⟹
Send(e, D, _, _, a, p)
⟹
Recv(e, C, _, _, a, p)
3. Сети Kubernetes как сетевые графы
В этом разделе описывается сетевая модель Kubernetes с точки зрения сетевого графа Kubernetes, идеализированной модели.
На рисунке 5 показан пример, использованный в этом разделе: Kubernetes Cluster K₁, состоящий из двух узлов. Каждый узел содержит два модуля. Каждый Pod выполняет два контейнера, один из которых прослушивает порт 8080, один контейнер прослушивает порт 9090. Кроме того, на каждом узле размещается один демон.
Рисунок 5. Kubernetes Cluster K₁
Мы можем смоделировать кластерную сеть Kubernetes в виде графика с набором узлов и набором ссылок.
3.1 Узлы
Каждый контейнер C K8s отображается на сетевой процесс C
K8s-Pod(P) ∧ K8s-Container(C, P):
Process(C)
Каждый демон D отображается на сетевой процесс C
K8s-Daemon(D):
Process(D)
Каждый модуль K8s Pod P сопоставляется с сетевым коммутатором P, коммутатор Pod
K8s-Pod(P):
Switch(P)
Каждый узел N K8s соответствует сетевому коммутатору N, коммутатору узла.
K8s-Pod(N):
Switch(N)
3.2 Ссылки
Каждый контейнер C связан со своим Pod Switch P
K8s-Pod(P) ∧ K8s-Container(C, P):
link(C, P)
Каждый демон D связан со своим Node Switch N
K8s-Node(N) ∧ K8s-Daemon(D):
host(N, D)
⟹
link(D, N)
Каждый Pod Switch P связан со своим Node Switch N
K8s-Node(N) ∧ K8s-Pod(P):
host(N, P)
⟹
link(P, N)
Каждый коммутатор Node Switch N связан с каждым другим коммутатором узла N
K8s-Node(N₁) ∧ K8s-Node(N₂):
N₁ ≠ N₂
⟹
link(N₁, N₂)
3.3 Передовая информационная база на переключателе Pod
Рисунок 6. Прямая информационная база P₁
1. Delivery on localhostK8s-Pod(P) ∧ K8s-Container(C, P):
open(C, p)
⟹
[* * 127.0.0.1 p Deliver(C)] in FIB[P]2. Delivery on Pod AddressK8s-Pod(P) ∧ K8s-Container(C, P):
addr(P, a) ∧ open(C, p)
⟹
[* * a p Deliver(C)] in FIB[P]3. Local Forwarding RuleK8s-Node(N) ∧ K8s-Pod(P):
host(N, P)
⟹
[* * * * Forward(N)] in FIB[P]
3.4 Прямая информационная база на коммутаторе узла
Рисунок 7. База прямой информации N₁
1. Node to Pod Forwarding RuleK8s-Node(N) ∧ K8s-Pod(P):
host(N, P) ∧ addr(P, a)
⟹
[* * a * Forward(P)] in FIB[N]2. Node to Node Forwalding RuleK8s-Node(N₁) ∧ K8s-Node(N₂) ∧ K8s-Pod(P):
N₁ ≠ N₂ ∧ host(N₂, P) ∧ addr(P, a)
⟹
[* * a * Forward(N₂)] in FIB[N₁]
Примеры
В этом разделе рассматриваются некоторые примеры и рассказывается о жизни сообщения в кластерной сети Kubernetes K₁.
Контейнер в контейнер
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₁.₂:
C₁.₁ выполняется в контексте Pod P₁
C₁.₂ выполняется в контексте Pod P₁
Рисунок 8. C₁.₁ to C₁.₂ via 127.0.0.1:9090
Связь от модуля к поду, внутриузел
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₃.₁:
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
C₃.₁ выполняется в контексте Pod P₃, который размещен на Node N.
Рисунок 9. C₁.₁ to C₃.₁ via 10.1.1.2:8080
Связь от модуля к поду, межузел
Здесь контейнер C₁.₁ должен взаимодействовать с контейнером C₂.₁:
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
C₂.₁ выполняется в контексте Pod P₂, который размещен на Node N.
Рисунок 10. C₁.₁ to C₂.₁ via 10.1.2.1:8080
Deamon to Pod Связь
Здесь Daemon D должен взаимодействовать с контейнером C₁.₁:
D₁ размещен на Node N.
C₁.₁ выполняется в контексте Pod P₁, который размещен на Node N.
Рисунок 11. D₁ to C₁.₁ via 10.1.1.1:8080
Заключение
Сетевая модель Kubernetes - это разрешающая сетевая модель, то есть любая сеть, которая удовлетворяет ограничениям сетевой модели Kubernetes, является допустимой сетью Kubernetes.
Сопоставление сетевой модели Kubernetes с сетевым графом позволяет нам рассуждать о сети на концептуальном уровне, пропуская множество деталей, которые были бы необходимы, если бы мы рассуждали на уровне реализации.
В последующих публикациях блога мы будем повторно использовать этот сетевой график для обсуждения Kubernetes Services, Kubernetes Ingress и политик Kubernetes.
Перевод статьи с сайта: https://dominik-tornow.medium.com/