Запуск кластера kubernetes kubeadm за корпоративным брандмауэром / прокси-сервером
У нас есть 5-узловый кластер, который был перемещен за наш корпоративный брандмауэр / прокси-сервер.
Согласно указаниям здесь: настройка-автономный-kubernetes-кластер-за-корпоративный-прокси
Я устанавливаю переменные окружения прокси-сервера, используя:
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, поэтому я бы предположил, что это связано с тем, что наш сервер не может загружать новые образы при перезагрузке.
3 ответа
Похоже, вы неправильно понимаете некоторые концепции 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-адрес, используемый для ссылки на сервер API Kubernetes в модулях. Кажется, что calico/node модуль, работающий на вашем узле, не может связаться с сервером API. Не могли бы вы рассказать о том, как настроить Calico? Вы знаете, какую версию Calico вы используете?
Тот факт, что ваш calico/node Экземпляр пытается получить доступ к crd.projectcalico.org/v1/clusterinformations ресурс говорит мне, что он использует хранилище данных Kubernetes для своего бэкэнда. Вы уверены, что не пытаетесь запустить Calico в режиме Etcd?
Эта проблема обычно означает, что демон Docker не может ответить.
Если существует какая-либо другая служба, потребляющая больше ресурсов ЦП или В / В, эта проблема может возникнуть.
Кажется, у вас нет проблем с потягиванием изображения, так как вы должны увидеть 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 портит но ваша ошибка не похожа связана с этим.