Подсети в кластере Kubernetes - PullRequest
0 голосов
/ 06 мая 2020

У меня есть несколько развертываний - скажем, развертывание A и развертывание B. K8s Su bnet - 10.0.0.0/20. Мое требование: возможно ли получить все модули в развертывании A, чтобы получить IP-адрес от 10.0.1.0/24, и модули в развертывании B с 10.0.2.0/24. Это помогает очистить сеть и с помощью самого IP может быть идентифицировано конкретное развертывание.

1 Ответ

1 голос
/ 06 мая 2020

Развертывание в Kubernetes - это абстракция высокого уровня, которая полагается на контроллеры для создания базовых c объектов. Это отличается от самого объекта, такого как модуль или служба.

Если вы посмотрите на развертывания spe c в Kubernetes API Overview , вы заметите, что нет такой вещи, как определение подсетей, ни IP-адреса, которые были бы указаны c для развертывания, поэтому вы не можете указать подсети для развертываний.

Идея Kubernetes заключается в том, что под эфемерным. Не следует пытаться идентифицировать ресурсы по IP-адресам, поскольку IP-адреса назначаются случайным образом. Если капсула умирает, у нее будет другой IP-адрес. Если вам нужны уникальные стабильные сетевые идентификаторы, вы можете попробовать посмотреть что-то вроде набора состояний.

Хотя Kubernetes не поддерживает эту функцию, я нашел обходной путь с помощью функции Calico: Migrate Pool .

Сначала вам нужно установить calicoctl. Есть несколько способов сделать это, упомянутые в install calicoctl docs.

Я выбираю установку calicoctl в качестве модуля Kubernetes:

 kubectl apply -f https://docs.projectcalico.org/manifests/calicoctl.yaml

Чтобы ускорить работу, вы можете настроить псевдоним:

alias calicoctl="kubectl exec -i -n kube-system calicoctl /calicoctl -- "

Я создал два yaml для настройки пулов ip:

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: pool1 
spec:
  cidr: 10.0.0.0/24
  ipipMode: Always
  natOutgoing: true

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: pool2 
spec:
  cidr: 10.0.1.0/24
  ipipMode: Always
  natOutgoing: true

Затем вы применили следующую конфигурацию, но поскольку мой yaml помещался в файловую систему моего хоста, а не в сам модуль calico, я поместил yaml как вход в команда:

➜  cat ippool1.yaml | calicoctl apply -f-
Successfully applied 1 'IPPool' resource(s)
➜  cat ippool2.yaml | calicoctl apply -f-
Successfully applied 1 'IPPool' resource(s)

В списке ippools вы заметите новые добавленные:

➜  calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   VXLANMODE   DISABLED   SELECTOR   
default-ipv4-ippool   192.168.0.0/16   true   Always     Never       false      all()      
pool1                 10.0.0.0/24      true   Always     Never       false      all()      
pool2                 10.0.1.0/24      true   Always     Never       false      all() 

Затем вы можете указать, какой пул вы хотите выбрать для развертывания:

--- 
metadata: 
  labels: 
    app: nginx
    name: deployment1-pool1
spec: 
  replicas: 3
  selector: 
    matchLabels: 
      app: nginx
  template: 
    metadata: 
      annotations: 
        cni.projectcalico.org/ipv4pools: "[\"pool1\"]"
 --- 

Я создал аналогичный под названием deployment2, который использовал ippool2 со следующими результатами:

deployment1-pool1-6d9ddcb64f-7tkzs    1/1     Running   0          71m   10.0.0.198        acid-fuji   
deployment1-pool1-6d9ddcb64f-vkmht    1/1     Running   0          71m   10.0.0.199        acid-fuji   
deployment2-pool2-79566c4566-ck8lb    1/1     Running   0          69m   10.0.1.195        acid-fuji   
deployment2-pool2-79566c4566-jjbsd    1/1     Running   0          69m   10.0.1.196        acid-fuji   

Также стоит упомянуть, что во время тестирования я обнаружил, что если ваше развертывание по умолчанию будет иметь много реплик и будут исчерпаны IPS. Затем Calico будет использовать другой пул.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...