Как увеличить диапазон CIDR подов в кластере Kubernetes, развернутом с помощью kubeadm?

Я развернул свой кластер с добавленным параметром --pod-network-cidr и создал новый пул IP-адресов с помощью calicoctl, чтобы изменить поды на этот диапазон. Проблема, с которой я столкнулся, - это именно то, что мне нужно изменить на стороне kubernetes, чтобы изменить диапазон cidr пода? Вношу ли я изменения в сервер API, диспетчер контроллеров и планировщик, или мне нужно изменить только определенные части. Я попытался изменить только диспетчер контроллеров, и эти модули уровня управления попадают в цикл сбоя после изменения --cluster-cidr в yaml.

Вывод в логах контроллера-менеджера ниже?

controllermanager.go: 235] ошибка запуска контроллеров: не удалось пометить cidr [192.168.0.0/24] на idx [0] как занятый для узла:: cidr 192.168.0.0/24 вне диапазона кластера cidr 10.0.0.0/16


person maxman722    schedule 11.02.2020    source источник


Ответы (1)


Изменить кластерный CIDR - непростая задача. Мне удалось воспроизвести ваш сценарий и изменить его, выполнив следующие действия.

Изменение пула IP-адресов

Процесс выглядит следующим образом:

  1. Установите calicoctl как модуль Kubernetes (Source < / а>)
  2. Добавьте новый пул IP-адресов (Источник).
  3. Отключите старый пул IP-адресов. Это предотвращает выделение нового IPAM из старого пула IP-адресов, не влияя на сетевое взаимодействие существующих рабочих нагрузок.
  4. Изменить параметры узлов podCIDR (Источник)
  5. Измените --cluster-cidr на kube-controller-manager.yaml на главном узле. (Кредиты OP по этому поводу)
  6. Восстановите все существующие рабочие нагрузки, которым был назначен адрес из старого пула IP-адресов.
  7. Удалите старый пул IP-адресов.

Давайте начнем.

В этом примере мы собираемся заменить 192.168.0.0/16 на 10.0.0.0/8.

  1. Установка calicoctl в качестве модуля Kubernetes
    $ kubectl apply -f https://docs.projectcalico.org/manifests/calicoctl.yaml
    
    Установка псевдонима:
    $ alias calicoctl="kubectl exec -i -n kube-system calicoctl -- /calicoctl "
    
  2. Добавьте новый пул IP:

    calicoctl create -f -<<EOF
    apiVersion: projectcalico.org/v3
    kind: IPPool
    metadata:
      name: new-pool
    spec:
      cidr: 10.0.0.0/8
      ipipMode: Always
      natOutgoing: true
    EOF
    

    Теперь у нас должно быть два включенных пула IP, которые мы можем увидеть при запуске calicoctl get ippool -o wide:

    NAME                  CIDR             NAT    IPIPMODE   DISABLED
    default-ipv4-ippool   192.168.0.0/16   true   Always     false
    new-pool              10.0.0.0/8       true   Always     false
    
  3. # P8 # # P9 #
    calicoctl get ippool -o yaml > pool.yaml
    
    # P10 #
    apiVersion: projectcalico.org/v3
    items:
    - apiVersion: projectcalico.org/v3
      kind: IPPool
      metadata:
        name: default-ipv4-ippool
      spec:
        cidr: 192.168.0.0/16
        ipipMode: Always
        natOutgoing: true
    - apiVersion: projectcalico.org/v3
      kind: IPPool
      metadata:
        name: new-pool
      spec:
        cidr: 10.0.0.0/8
        ipipMode: Always
        natOutgoing: true
    
    # P11 #
    # P12 #
    apiVersion: projectcalico.org/v3
    kind: IPPool
    metadata:5
      name: default-ipv4-ippool
    spec:
      cidr: 192.168.0.0/16
      ipipMode: Always
      natOutgoing: true
      disabled: true
    
    # P13 #
    calicoctl apply -f pool.yaml
    
    # P14 #
    NAME                  CIDR             NAT    IPIPMODE   DISABLED
    default-ipv4-ippool   192.168.0.0/16   true   Always     true
    new-pool              10.0.0.0/8       true   Always     false
    
  4. Измените параметр узлов podCIDR:

    Замените параметр podCIDR на конкретном ресурсе узла k8s новым диапазоном IP-адресов, желательно с помощью следующих команд:

    $ kubectl get no kubeadm-0 -o yaml > file.yaml; sed -i "s~192.168.0.0/24~10.0.0.0/16~" file.yaml; kubectl delete no kubeadm-0 && kubectl create -f file.yaml
    $ kubectl get no kubeadm-1 -o yaml > file.yaml; sed -i "s~192.168.1.0/24~10.1.0.0/16~" file.yaml; kubectl delete no kubeadm-1 && kubectl create -f file.yaml
    $ kubectl get no kubeadm-2 -o yaml > file.yaml; sed -i "s~192.168.2.0/24~10.2.0.0/16~" file.yaml; kubectl delete no kubeadm-2 && kubectl create -f file.yaml    
    

    Мы должны были выполнить это действие для каждого имеющегося у нас узла. Обратите внимание на диапазоны IP-адресов, они различаются от одного узла к другому.

  5. Измените CIDR в kubeadm-config ConfigMap и kube-controller-manager.yaml

Отредактируйте kubeadm-config ConfigMap и измените podSubnet на новый диапазон IP-адресов:

kubectl -n kube-system edit cm kubeadm-config

Также измените --cluster-cidr в /etc/kubernetes/manifests/kube-controller-manager.yaml, расположенном на главном узле.

$ sudo cat /etc/kubernetes/manifests/kube-controller-manager.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --bind-address=127.0.0.1
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --cluster-cidr=10.0.0.0/8
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --controllers=*,bootstrapsigner,tokencleaner
    - --kubeconfig=/etc/kubernetes/controller-manager.conf
    - --leader-elect=true
    - --node-cidr-mask-size=24
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --root-ca-file=/etc/kubernetes/pki/ca.crt
    - --service-account-private-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --use-service-account-credentials=true
  1. Восстановите все существующие рабочие нагрузки, используя IP-адреса из отключенного пула. В этом примере kube-dns - единственная рабочая нагрузка, подключенная к сети Calico:

    kubectl delete pod -n kube-system kube-dns-6f4fd4bdf-8q7zp
    

    Убедитесь, что новая рабочая нагрузка теперь имеет адрес в новом пуле IP-адресов, запустив calicoctl get wep --all-namespaces:

    NAMESPACE     WORKLOAD                   NODE      NETWORKS            INTERFACE
    kube-system   kube-dns-6f4fd4bdf-8q7zp   vagrant   10.0.24.8/32   cali800a63073ed
    
  2. Удалите старый пул IP:

    calicoctl delete pool default-ipv4-ippool
    

Правильное создание с нуля

Чтобы развернуть кластер под определенным диапазоном IP-адресов с помощью Kubeadm и Calico, вам необходимо инициализировать кластер с помощью --pod-network-cidr=192.168.0.0/24 (где 192.168.0.0/24 - ваш желаемый диапазон), а затем вам необходимо настроить манифест Calico перед его применением в новом кластере.

Чтобы настроить Calico перед применением, вам необходимо загрузить его yaml-файл и изменить диапазон сети.

  1. Загрузите сетевой манифест Calico для Kubernetes.
    $ curl https://docs.projectcalico.org/manifests/calico.yaml -O
    
  2. Если вы используете модуль CIDR 192.168.0.0/24, перейдите к следующему шагу. Если вы используете другой CIDR модуля, используйте следующие команды, чтобы установить переменную среды с именем POD_CIDR, содержащую CIDR вашего модуля, и заменить 192.168.0.0/24 в манифесте на CIDR вашего модуля.
    $ POD_CIDR="<your-pod-cidr>" \
    sed -i -e "s?192.168.0.0/16?$POD_CIDR?g" calico.yaml
    
  3. Примените манифест с помощью следующей команды.
    $ kubectl apply -f calico.yaml
    
person Mark Watney    schedule 12.02.2020
comment
Если мы изначально создали кластер, выполнив описанные выше действия, а затем осознали, что нам нужно расширить диапазон, чтобы включить в него больше IP-адресов, есть ли способ внести это изменение? Мы развернули таким образом и имеем упомянутую потребность, без необходимости перестраивать весь кластер. - person maxman722; 12.02.2020
comment
Я обновил свой ответ, включая инструкции по его изменению без необходимости перестраивать кластер. - person Mark Watney; 13.02.2020
comment
при жестком кодировании CIDR пода в узлах на шаге 4 (это делается на главном и рабочем узлах, правильно?) всякий раз, когда мы добавляем дополнительные рабочие узлы в кластер, будут ли они автоматически назначать следующий IP-адрес в диапазоне? например, в приведенном выше мастере 1 - 192.168.0.0, на главном 2 - 192.168.1.0, на главном 3 - 192.168.2.0 ..... рабочие узлы продолжат работу по этому шаблону для 3, 4, 5 и т. д., будет ли следующий рабочий узел выбирает этот диапазон и ему назначается 6 (или следующий доступный IP-адрес в диапазоне? Кроме того, нужно ли это делать в определенном порядке, чтобы убедиться, что мы постоянно поддерживаем мастера в рабочем состоянии - person maxman722; 13.02.2020
comment
Итак ... в дополнение к вышесказанному, похоже, вам нужно вручную отредактировать /etc/kubernetes/manifests/kube-controller-manager.yml на новый cidr. как только это будет изменено, похоже, что изменение завершено - person maxman722; 14.02.2020
comment
Я подтвердю это и, если это действительно необходимо, обновлю свой ответ, в том числе с помощью кредитов. Рад, что вам удалось завершить изменение - person Mark Watney; 14.02.2020
comment
Еще вопрос по диапазонам. Ничего страшного, если диапазоны узлов перекрываются? Или узлы должны иметь / 24, так как каждому узлу будет назначен диапазон в пределах общего диапазона cidr calico pod? - person maxman722; 14.02.2020
comment
Что касается приведенного выше комментария, я думаю о 10.0.0.0/16, 10.0.1.0/16 и 10.0.2.0/16. Поскольку диапазон / 16 теперь будет включать друг друга, поскольку это не просто / 24 на узел - person maxman722; 14.02.2020
comment
Для меня это имеет смысл. Вероятно, было бы неплохо использовать 10.0.0.0/16, 10.1.0.0/16 и 10.2.0.0/16. - person Mark Watney; 14.02.2020
comment
Я отредактировал свой ответ, включая упомянутые вами пункты и дополнительное изменение в kubeadm-config ConfigMap. - person Mark Watney; 14.02.2020
comment
Меня смущают диапазоны IP-адресов, используемые в примере. Пул IP-адресов, определенный в calico, - 10.0.0.0/16, но узлы используют 10.1.0.0/16 и 10.2.0.0/16 - эти IP-адреса не включены в диапазон пула IP-адресов calico, поэтому как они используются для переменной узла для диапазона IP-адресов? Можете ли вы подтвердить правильность указанной выше конфигурации? - person maxman722; 19.02.2020
comment
Я считаю, что ссылка ниже - причина, по которой это работает. IPAM ситца не следует за cidr модуля, указанным на узле, скорее он использует свой собственный диапазон и отправляет его на узлы: github.com/projectcalico/calico/issues/2592 - person maxman722; 19.02.2020
comment
@ mm_wvu18 спасибо, что подняли эту тему. Я просмотрел его и понял, что вы правы, они не могут быть в той же сети, что я описал. Я отредактировал руководство, основываясь на изменении с 192.168.0.0/16 на 10.0.0.0/8. Это имеет больше смысла и упростит понимание этого руководства. - person Mark Watney; 19.02.2020
comment
Я не уверен, что эта переменная имеет значение в первую очередь, поскольку кажется, что CIDR на узлах назначаются и выбираются случайным образом (не на основе IP-адреса, который вы назначаете в файле file.yaml, используемом выше. Это может использовать описание в моем предыдущем комментарии (относительно Calico IPAM). - person maxman722; 20.02.2020