Я создаю кластер Kubernetes в соответствии с этим руководство, и у меня возникают проблемы с доступом к панели управления Kubernetes. Я уже создавал другой вопрос по этому поводу, что видно здесь, но пока копался в моем кластере, я думаю, что проблема может быть где-то еще и поэтому я создаю новый вопрос.
Я запускаю свой мастер, выполнив следующие команды:
> kubeadm reset
> kubeadm init --apiserver-advertise-address=[MASTER_IP] > file.txt
> tail -2 file.txt > join.sh # I keep this file for later
> kubectl apply -f https://git.io/weave-kube/
> kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
coredns-fb8b8dccf-kb2zq 0/1 Pending 0 2m46s
coredns-fb8b8dccf-nnc5n 0/1 Pending 0 2m46s
etcd-kubemaster 1/1 Running 0 93s
kube-apiserver-kubemaster 1/1 Running 0 93s
kube-controller-manager-kubemaster 1/1 Running 0 113s
kube-proxy-lxhvs 1/1 Running 0 2m46s
kube-scheduler-kubemaster 1/1 Running 0 93s
Здесь мы видим, что два модуля coredns
навсегда застряли в состоянии ожидания, и когда я запускаю команду:
> kubectl -n kube-system describe pod coredns-fb8b8dccf-kb2zq
Я вижу в части событий следующее предупреждение:
Failed Scheduling : 0/1 nodes are available 1 node(s) had taints that the pod didn't tolerate.
Поскольку это предупреждение, а не ошибка, и это как новичок в Kubernetes, taints
для меня мало что значит, я попытался подключить узел к мастеру (используя ранее сохраненную команду):
> cat join.sh
kubeadm join [MASTER_IP]:6443 --token [TOKEN] \
--discovery-token-ca-cert-hash sha256:[ANOTHER_TOKEN]
> ssh [USER]@[WORKER_IP] 'bash' < join.sh
This node has joined the cluster.
На мастере проверяю, что нода подключена:
> kubectl get nodes
NAME STATUS ROLES AGE VERSION
kubemaster NotReady master 13m v1.14.1
kubeslave1 NotReady <none> 31s v1.14.1
И я проверяю свои стручки:
> kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
coredns-fb8b8dccf-kb2zq 0/1 Pending 0 14m
coredns-fb8b8dccf-nnc5n 0/1 Pending 0 14m
etcd-kubemaster 1/1 Running 0 13m
kube-apiserver-kubemaster 1/1 Running 0 13m
kube-controller-manager-kubemaster 1/1 Running 0 13m
kube-proxy-lxhvs 1/1 Running 0 14m
kube-proxy-xllx4 0/1 ContainerCreating 0 2m16s
kube-scheduler-kubemaster 1/1 Running 0 13m
Мы видим, что еще один модуль kube-proxy был создан и застрял в статусе ContainerCreating.
И когда я снова делаю описание:
kubectl -n kube-system describe pod kube-proxy-xllx4
Я вижу в части событий несколько одинаковых предупреждений:
Failed create pod sandbox : rpx error: code = Unknown desc = failed pulling image "k8s.gcr.io/pause:3.1": Get https://k8s.gcr.io/v1/_ping: dial tcp: lookup k8s.gcr.io on [::1]:53 read up [::1]43133->[::1]:53: read: connection refused
Вот мои репозитории:
docker image ls
REPOSITORY TAG
k8s.gcr.io/kube-proxy v1.14.1
k8s.gcr.io/kube-apiserver v1.14.1
k8s.gcr.io/kube-controller-manager v1.14.1
k8s.gcr.io/kube-scheduler v1.14.1
k8s.gcr.io/coredns 1.3.1
k8s.gcr.io/etcd 3.3.10
k8s.gcr.io/pause 3.1
И так, для приборной части я попробовал запустить ее командой
> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml
Но модуль приборной панели застрял в состоянии ожидания.
kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
coredns-fb8b8dccf-kb2zq 0/1 Pending 0 40m
coredns-fb8b8dccf-nnc5n 0/1 Pending 0 40m
etcd-kubemaster 1/1 Running 0 38m
kube-apiserver-kubemaster 1/1 Running 0 38m
kube-controller-manager-kubemaster 1/1 Running 0 39m
kube-proxy-lxhvs 1/1 Running 0 40m
kube-proxy-xllx4 0/1 ContainerCreating 0 27m
kube-scheduler-kubemaster 1/1 Running 0 38m
kubernetes-dashboard-5f7b999d65-qn8qn 1/1 Pending 0 8s
Итак, хотя моя проблема изначально заключалась в том, что я не могу получить доступ к своей панели инструментов, я думаю, что настоящая проблема глубже.
Я знаю, что просто разместил здесь много информации, но я новичок в k8s и совершенно не понимаю этого.
На самом деле это противоположность глубокой или серьезной проблеме. Это тривиальная проблема. Всегда вы видите модуль, застрявший в состоянии Pending
, это означает, что планировщику трудно запланировать модуль; в основном потому, что на узле недостаточно ресурсов.
В вашем случае это taint
, у которого есть узел, а у вашего модуля нет допуска. Что вам нужно сделать, так это описать узел и получить taint:
kubectl describe node | grep -i taints
Примечание: у вас может быть более одной порчи. Так что вы можете сделать kubectl describe no NODE
, так как с помощью grep вы увидите только один taint.
Как только вы получите порчу, это будет что-то вроде hello=world:NoSchedule
; что означает key=value:effect
, вам нужно будет добавить раздел toleration
в свой Deployment
. Это пример Deployment
, чтобы вы могли увидеть, как это должно выглядеть:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 10
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: http
tolerations:
- effect: NoExecute #NoSchedule, PreferNoSchedule
key: node
operator: Equal
value: not-ready
tolerationSeconds: 3600
Как видите, в yaml есть раздел допуска. Таким образом, если бы у меня был узел с node=not-ready:NoExecute
taint, ни один модуль не смог бы быть запланирован на этом узле, если бы не было этого допуска.
Также вы можете удалить taint
, если вам это не нужно. Чтобы удалить taint
, вы должны описать узел, получить key
загрязнения и сделать:
kubectl taint node NODE key-
Надеюсь, это имеет смысл. Просто добавьте этот раздел в свое развертывание, и все заработает.
Да, эти порчи имеют смысл. Это делается для того, чтобы ни один под не запускался на главном узле (если он не предназначен) и никакие поды не должны работать на узле с определенными проблемами (не готовый узел). Просто добавьте допуски, как объяснено, к вашим развертываниям (например, core-dns), и все должно работать. P.S. ваша проблема не имеет ничего общего с сетевыми плагинами. По крайней мере тот, который вы описываете.
Ну, на самом деле дело в том, что мой coredns застрял в ожидании с предупреждением о недопустимых заражениях, и как только я правильно запустил сетевой плагин, статус coredns переходит в «Выполняется». Я не знаю, имеет ли это смысл, но это то, что произошло.
Это не имеет для меня никакого смысла. Если только ваш узел не был испорчен как not-ready
из-за того, что плагин не был установлен. В этом случае заражение будет удалено, как только узел будет готов. Если вы бежите kubectl describe node NODE
, у вас все еще есть порчи?
Теперь у меня есть только порча node-role.kubernetes.io/master:NoSchedule
Это имеет смысл для меня. Узел был динамически испорчен.
Я столкнулся с проблемой, когда модули coredns
застряли в режиме ожидания при настройке собственного кластера; который я разрешаю, добавляя сеть pod.
Похоже, что из-за того, что Network Addon не установлен, узлы испорчены как not-ready
. Установка аддона удалит загрязнения, и модули смогут планировать. В моем случае добавление фланель решило проблему.
Обновлено: об этом есть примечание в официальном Документация k8s - Создание кластера с помощью kubeadm:
The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed. kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).
Разве не для этого предназначен kubectl apply -f https://git.io/weave-kube/
?
Я заменил предыдущую команду на kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
, и теперь в моих модулях появляется weave-net. И с тех пор мои стручки coredns волшебным образом начали работать (как вы сказали :))
это зависит от того, как вы собираетесь «установить» свой pod-network
. Рад, что был полезен
Настройте сетевой инструмент фланели.
Запуск команд:
$ sysctl net.bridge.bridge-nf-call-iptables=1
$ kubectl apply -f
Спасибо за Ваш ответ ! На моем узле kubemaster обнаружены следующие дефекты:
node.kubernetes.io/not-ready:NoExecute
,node-role.kubernetes.io/master:NoSchedule
,node.kubernetes.io/not-ready:NoSchedule
. Я не понимаю, что я только выполнил командуkubeadm init --apiserver-advertise-address=[MASTER_IP]
. На данный момент у меня нет файла YAML. Нужно ли создавать новый файл развертывания?