Запуск кластера kubernetes kubeadm за корпоративным брандмауэром / прокси-сервером

У нас есть кластер из 5 узлов, который был перемещен за наш корпоративный брандмауэр / прокси-сервер.

В соответствии с указаниями здесь: настройка-автономный-кубернетес-кластер-за-корпоративный-прокси

Я установил переменные среды прокси-сервера, используя:

export http_proxy=http://proxy-host:proxy-port/
export HTTP_PROXY=$http_proxy
export https_proxy=$http_proxy
export HTTPS_PROXY=$http_proxy
printf -v lan '%s,' localip_of_machine
printf -v pool '%s,' 192.168.0.{1..253}
printf -v service '%s,' 10.96.0.{1..253}
export no_proxy="${lan%,},${service%,},${pool%,},127.0.0.1";
export NO_PROXY=$no_proxy

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

[gms@thalia0 ~]$ kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
pod/busybox created

застрял здесь:

[gms@thalia0 ~]$ kubectl get pods
NAME                            READY   STATUS              RESTARTS   AGE
busybox                         0/1     ContainerCreating   0          17m

Я предполагаю, что это связано с тем, что хост / домен, из которого извлекается изображение, не входит в наши корпоративные правила прокси. У нас есть правила для

k8s.io
kubernetes.io
docker.io
docker.com

поэтому я не уверен, какие еще хосты / домены нужно добавить.

Я описал модули для busybox и вижу ссылку на node.kubernetes.io (я добавляю исключение для всего домена для *.kubernetes.io, которого, надеюсь, будет достаточно).

Вот что я получаю от kubectl describe pods busybox:

Volumes:
  default-token-2kfbw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-2kfbw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age   From                          Message
  ----     ------                  ----  ----                          -------
  Normal   Scheduled               73s   default-scheduler             Successfully assigned default/busybox to thalia3.ahc.umn.edu
  Warning  FailedCreatePodSandBox  10s   kubelet, thalia3.ahc.umn.edu  Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "6af48c5dadf6937f9747943603a3951bfaf25fe1e714cb0b0cbd4ff2d59aa918" network for pod "busybox": NetworkPlugin cni failed to set up pod "busybox_default" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout, failed to clean up sandbox container "6af48c5dadf6937f9747943603a3951bfaf25fe1e714cb0b0cbd4ff2d59aa918" network for pod "busybox": NetworkPlugin cni failed to teardown pod "busybox_default" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout]
  Normal   SandboxChanged          10s   kubelet, thalia3.ahc.umn.edu  Pod sandbox changed, it will be killed and re-created.

Я предполагаю, что ошибка ситца связана с этим:

Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s

Модули calico и coredns, похоже, имеют похожие ошибки, достигающие node.kubernetes.io, поэтому я предполагаю, что это связано с тем, что наш сервер не может загрузить новые изображения при перезапуске.


kubernetes docker http-proxy corporate-policy
person horcle_buzz    schedule 05.04.2019    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Похоже, вы неправильно понимаете несколько концепций Kubernetes, которые я хотел бы здесь прояснить. Ссылки на node.kubernetes.io не являются попыткой выполнить какие-либо сетевые вызовы в этот домен. Это просто соглашение, которое Kubernetes использует для указания строковых ключей. Поэтому, если вам когда-либо придется применять метки, аннотации или допуски, вы должны определить свои собственные ключи, например subdomain.domain.tld/some-key.

Что касается проблемы с Calico, с которой вы столкнулись, она выглядит как ошибка:

network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout]

здесь наш виноват. 10.96.0.1 - это IP-адрес, используемый для обращения к серверу Kubernetes API в подах. Кажется, что модуль calico/node, запущенный на вашем узле, не может связаться с сервером API. Не могли бы вы подробнее рассказать о том, как вы настраивали Calico? Вы знаете, какую версию Calico вы используете?

Тот факт, что ваш экземпляр calico/node пытается получить доступ к ресурсу crd.projectcalico.org/v1/clusterinformations, говорит мне, что он использует хранилище данных Kubernetes для своего внутреннего интерфейса. Вы уверены, что не пытаетесь запустить Calico в режиме Etcd?

person brianSan    schedule 06.04.2019
comment
Спасибо за обзор. Да, я понял, что node.kubernetes.io была внутренней ссылкой и что ошибка была связана с невозможностью связаться с сервером api. Все в режиме по умолчанию. Причина заключалась в том, что докер не мог извлекать новые образы, а k8s не мог перестроить контейнеры для развертывания новых модулей. - person horcle_buzz; 06.04.2019
comment
рад, что ты понял это! - person brianSan; 06.04.2019

arrow_upward
0
arrow_downward

Похоже, у вас нет проблем с получением изображения, вы должны увидеть статус ImagePullBackOff. (Хотя это может появиться позже после сообщения об ошибке, которое вы видите)

Ошибка, которую вы видите в своих модулях, связана с тем, что они не могут внутренне подключиться к kube-apiserver. Это похоже на тайм-аут, поэтому, скорее всего, в вашем пространстве имен по умолчанию что-то есть со службой kubernetes. Проверить это можно, например:

$ kubectl -n default get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   2d20h

Может быть, что-то отсутствует (?) Вы всегда можете воссоздать его:

$ cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
spec:
  clusterIP: 10.96.0.1
  type: ClusterIP
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
EOF

Терпимость в основном говорит о том, что под может быть запланировано на узле, который имеет загрязнения node.kubernetes.io/not-ready:NoExecute и node.kubernetes.io/unreachable:NoExecute, но ваша ошибка, похоже, не связана с этим.

person Rico    schedule 05.04.2019
comment
Я думаю, что это могло быть из-за того, что я не настроил правила прокси на неосновных узлах, а затем перезапустил докер и кубелет, но я разочаровался и просто разобрал и перестроил кластер, и теперь все полностью работает. Когда я впервые разобрал его и перестроил узлы, мне не удалось вытащить изображения, но после добавления правил прокси и перезапуска все было в порядке. Интересная гипотеза, хотя и выдвинутая вами. Не собираюсь тестировать, так как все работает. - person horcle_buzz; 06.04.2019

arrow_upward
0
arrow_downward

Проблема обычно означает, что демон докера не может ответить.

Эта проблема может возникнуть, если какая-либо другая служба потребляет больше ресурсов ЦП или операций ввода-вывода.

person Akash Sharma    schedule 06.04.2019
comment
Да, см. Мой комментарий выше. Я понял проблему. Прокси-сервер не был настроен для рабочих узлов, поэтому они не могли получать изображения. - person horcle_buzz; 06.04.2019