У меня такая же проблема. Я также попытался удалить Network ARGS, как было предложено по другой проблеме. Он все еще висит на waiting for control plane to be ready .

Вы перезагрузили Daemon и перезапустили службу kubelet после внесения изменений. Заработало после смены драйвера и комментирования сети. В первый раз мне требуется от 10 до 11 минут, чтобы самолет управления был готов, я бы посоветовал оставить его на 15 минут в первый раз.

Я перезагружала демона и каждый раз перезапускала службу kubelet. Я даже оставил установку нетронутой на всю ночь, но она все еще ждала контрольный самолет.

Я перезагрузил демон ( systemctl daemon-reload ) и перезапустил kubelet. Я запускаю kubeadm reset , редактирую конфигурацию службы, перезагружаю демон, затем запускаю kubeadm init .

Docker-контейнеры Apiserver и etcd не запускаются после комментирования параметров сети. Я также пытался установить weave-net вручную, чтобы каталог конфигурации cni был заполнен, но это тоже не сработало. Для этого я установил weave, запустил weave setup и weave launch . Я действительно не знаю, как Kubeadm настраивает Docker для использования настроек CNI, но, возможно, здесь я упускаю какой-то шаг.

Похоже, kubelet не может подключиться к серверу kube api.

Я заметил, что etcd не может прослушивать порт 2380, я снова выполнил эти шаги, и мой кластер запустился:

• Запустите kubeadm reset , чтобы удалить все изменения, сделанные на сервере.
• Верните машину в исходное состояние. Переустановив kubeadm (чтобы вернуть исходные файлы конфигурации).
• Удалите контейнеры докеров, связанные с kubernetes, если они есть.
• Получить и установить плетение. Не запускай его.
• Перезагрузите сервер.
• Убедитесь, что kubelet не запускается.
• Запустите weave setup и weave launch .
• Выполнить kubeadm init .

Если вы хотите избавиться от управления плетением вручную...

• Выполнить weave reset
• Примените надстройку weave для kubernetes 1.6.
• Перезагрузите сервер.

Присоединение Kubeadm должно работать на других серверах.

@Yengas Не могли бы вы предоставить более подробную информацию об этапах плетения? Вы запускали их на всех нодах или только на мастере?

@jruels просто главный узел. Weave — это всего лишь один двоичный файл. Команда setup без каких-либо аргументов загружает образы докеров weave и создает конфигурацию CNI. Команда запуска без каких-либо аргументов запускает контейнеры плетения только на хосте.

@Yengas Все еще не уверен, что вы имеете в виду под «получить и установить weave. Не запускайте его». Очевидно, я не могу сделать kubectl apply -f https://git.io/weave-kube-1.6 , так как мне установить weave ?

Что говорят журналы apiserver?

@rushabh268
Чтобы установить weave, запустите на мастере следующее:
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
Затем запустите
weave setup
Когда это завершится
weave launch

вам не нужно этого делать. kubectl apply -f https://git.io/weave-kube-1.6 должно быть достаточно.

Журналы сервера API говорят то же самое, что я упоминал в ошибке. Кроме того, я не могу сделать kubectl, потому что Kubernetes не установлен

@jruels Я попробую и обновлю эту тему!

В описании ошибки есть логи kubeadm и логи kubelet. Логов аписервера нет.

@mikedanese Как мне получить журналы apiserver?
@jruels Я могу поднять тему плетения
@Yengas Даже после ваших шагов я вижу следующую ошибку в журналах kubelet:
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

Кроме того, я остановил брандмауэр, поэтому не знаю, почему мне отказывают в соединении.

У меня такая же проблема, о которой сообщают здесь.

Снимок из моих системных сообщений (Master Node), пока он завис, на всякий случай, он на что-то указывает. Кстати, я исполняю это на Linode.

12 апреля 02:10:00 аудит локального хоста: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? адрес=? терминал =? рез = успех'
12 апреля 02:10:00 аудит локального хоста: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? адрес=? терминал =? рез = успех'
12 апреля 02:10:00 аудит локального хоста: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? адрес=? терминал =? рез = успех'
12 апреля, 02:10:00 localhost systemd: kubelet.service: Время задержки службы истекло, запланирован перезапуск.
12 апреля 02:10:00 localhost systemd: остановлен kubelet: агент узла Kubernetes.
12 апреля 02:10:00 localhost systemd: запущен kubelet: агент узла Kubernetes.
12 апр, 02:10:00 localhost systemd: запуск инструмента учета активности системы...
12 апреля 02:10:00 аудит локального хоста: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? адрес=? терминал =? рез = успех'
12 апреля 02:10:00 аудит локального хоста: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? адрес=? терминал =? рез = успех'
12 апреля 02:10:00 localhost systemd: Запущен инструмент учета активности системы.
12 апреля 02:10:00 localhost kubelet: I0412 02:10:00.924529 3445 feature_gate.go:144] feature gates: map[]
12 апреля 02:10:00 localhost kubelet: I0412 02:10:00.928973 3445 docker.go:364] Подключение к докеру на unix:///var/run/docker.sock
12 апреля 02:10:00 localhost kubelet: I0412 02:10:00.929201 3445 docker.go:384] Запустите клиент Docker с тайм-аутом запроса = 2 м0 с
12 апреля 02:10:00 localhost kubelet: W0412 02:10:00.941088 3445 cni.go:157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
12 апреля 02:10:00 localhost kubelet: I0412 02:10:00.948892 3445 manager.go:143] cAdvisor работает в контейнере: "/system.slice"
12 апреля 02:10:00 localhost kubelet: W0412 02:10:00.974540 3445 manager.go:151] невозможно подключиться к службе API Rkt: rkt: невозможно tcp Набрать службу API rkt: набрать tcp [::1]:15441: getsockopt: в соединении отказано
12 апреля 02:10:00 localhost kubelet: I0412 02:10:00.997599 3445 fs.go:117] Разделы файловой системы: map[/dev/root:{точка монтирования:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 blockSize:0 }]
12 апреля 2:10:01 локальный kubelet: I0412 02: 10: 01,001662 3445 manager.go: 198] Машина: { NumCores: 1 Cpu Частота: 2799998 Memor yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID: 5e9a9a0b58984bfb8766dba9afa8a191 BOOTID: 7ed1a6ff-9848- 437b-9460-981eeefdfe5a Файловые системы: [{Устройство:/dev/root Емкость:15447539712 Тип:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ Имя:nbd0 Major:43 Minor:0 Размер:0 Scheduler:none } 43:11:{ Name:nbd11 Major:43 Minor:11 Size:0 Scheduler:none } 43:12:{ Name:nbd12 Major:43 Minor:12 Size:0 Scheduler:none } 43:15: { Имя:nbd15 Основной:43 Дополнительный :15 Размер:0 Планировщик:нет } 43:7:{ Имя:nbd7 Основной:43 Дополнительный :7 Размер:0 Планировщик:нет } 8:0:{ Имя:sda Основной:8 Дополнительный :0 Size:15728640000 Scheduler:cfq } 252:0:{ Name:dm-0 Major:252 Minor:0 Size:107374182400 Scheduler:none } 43:1:{ Name:nbd1 Major:43 Minor:1 Size:0 Scheduler :none } 43:13:{ Имя:nbd13 Основной:43 Дополнительный :13 Размер:0 Планировщик:нет } 43:8:{ Имя:nbd8 Основной:43 Дополнительный :8 Размер:0 Планировщик:нет } 8: 16:{ Имя:sdb Major:8 Minor:16 Size:536870912 Scheduler:cfq } 9:0:{ Name:md0 Major:9 Minor:0 Size:0 Scheduler:none } 43:3:{ Name:nbd3 Major: 43 Младший:3 Размер:0 Планировщик:нет } 43:9:{ Имя:nbd9 Основной:43 Младший:9 Размер:0 Планировщик:нет } 43:10:{ Имя:nbd10 Основной:43 Младший:10 Размер:0 Планировщик :none } 43:14:{ Имя:nbd14 Основной:43 Дополнительный :14 Размер:0 Планировщик:нет } 43:2:{ Имя:nbd2 Основной:43 Дополнительный :2 Размер:0 Планировщик:нет } 43:4:{ Имя:nbd4 Основной:43 Дополнительный :4 Размер:0 Планировщик:нет } 43:5:{ Имя:nbd5 Основной:43 Дополнительный :5 Размер:0 Планировщик:нет } 43:6:{ Имя:nbd6 Основной:43 Дополнительный : 6 Size:0 Scheduler:none }] NetworkDevices:[{ Name:dummy0 M acAddress:5a :34:bf:e4:23:cc Скорость:0 Mtu:1500 } { Name:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 Скорость: -1 Mtu:1500 } { Имя:gre0 M acAddress:00 :00:00:00 Скорость:0 Mtu:1476 } { Имя:gretap0 M acAddress:00 :00:00:00:00 :00 Скорость:0 Mtu:1462 } { Имя:ip6_vti0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Скорость:0 Mtu:1500 } { Имя:IP6gre0 M acAddress:00 :00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00 Скорость:0 Mtu:1448 } { Имя:ip6tnl0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 Скорость:0 Mtu:1452 } { Имя:ip_vti0 Ма
12 апреля 02:10:01 localhost kubelet: cAddress:00 :00:00:00 Скорость:0 Mtu:1428 } { Имя:sit0 M acAddress:00 :00:00:00 Скорость:0 Mtu:1480 } { Имя: teql0 MacAddress: Speed:0 Mtu:1500 } { Name:tunl0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 }] Топология:[{Id:0 Память:1037021184 Ядра:[{Id:0 Threads :[0] Кэши:[{ Размер:32768 Тип: Уровень данных:1 } { Размер:32768 Тип:Уровень инструкций :1 } { Размер:4194304 Тип:Унифицированный уровень:2 }]}] Кэши:[]}] Clou dProvider:Unknown InstanceType:Unknown I nstanceID:None }
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.013353 3445 manager.go:204] Версия: {Kern elVersion:4.9.15-x86_64-linode81 Container OsVersion: Fedora 25 (Server Edition) Dock erVersion: 1.12. 6 CadvisorVersion: CadvisorRevision:}
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos включен, но --cgroup-root не указан. по умолчанию /
12 апреля 02:10:01 localhost kubelet: W0412 02:10:01.016562 3445 container_manager_linux.go:218] Работа с включенной подкачкой не поддерживается, отключите подкачку! Это будет фатальная ошибка по умолчанию, начиная с K8s v1.6! Тем временем вы можете отказаться от фатальной ошибки, включив --experimental-fail-swap-on.
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.016688 3445 container_manager_linux.go:245] диспетчер контейнеров подтвердил, что указанный пользователем cgroup-root существует: /
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.016717 3445 container_manager_linux.go:250] Создание объекта Container Manager на основе конфигурации узла: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contain erRuntime:docker Cgroup upsPerQOS:true CgroupRoot:/ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable:map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] HardEvictionThresholds:[{ Signal:memory.available Operator :LessThan Value:{ Количество:100Mi Процент:0 } GracePeriod:0s MinReclaim:}]} ExperimentalQO SReserved:map []}
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.016943 3445 kubelet.go:255] Добавление файла манифеста: /etc/kubernetes/manifests
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.016966 3445 kubelet.go:265] Наблюдаю за apiserver
12 апреля 02:10:01 localhost kubelet: E0412 02:10:01.025058 3445 Reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Не удалось получить список *v1.Node: Получить https: //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0: наберите TCP 50.116.13.214:6443:getockopt: соединение отклонено
12 апреля 02:10:01 localhost kubelet: E0412 02:10:01.025342 3445 Reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: не удалось получить список *v1.Service: получить https: //50.116.13.214 :6443/api/v1/services?resourceVersion=0: наберите tcp 50.116.13.214:6443:getockopt: в соединении отказано
12 апреля 02:10:01 localhost kubelet: E0412 02:10:01.025397 3445 Reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: не удалось получить список *v1.Pod: получить https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0: наберите TCP 50.116.13.214:6443:getockopt: соединение отклонено
12 апреля 02:10:01 localhost kubelet: W0412 02:10:01.026574 3445 kubelet_network.go:70] Режим шпильки установлен на «неразборчивый мост», но kubenet не включен, возвращается к «шпильке-вет»
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.026599 3445 kubelet.go:494] Режим шпильки установлен на «шпилька-veth»
12 апреля 02:10:01 localhost kubelet: W0412 02:10:01.026661 3445 cni.go:157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
12 апреля 02:10:01 localhost kubelet: W0412 02:10:01.034194 3445 cni.go:157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
12 апреля 02:10:01 localhost kubelet: W0412 02:10:01.043157 3445 cni.go:157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
12 апреля 02:10:01 localhost kubelet: I0412 02:10:01.043183 3445 docker_service.go:187] Сеть Docker cri управляется cni
12 апреля 02:10:01 localhost kubelet: ошибка: не удалось запустить Kubelet: не удалось создать kubelet: неправильная конфигурация: драйвер cgroup kubelet: «cgroupfs» отличается от драйвера cgroup docker: «systemd»
12 апреля 02:10:01 аудит локального хоста: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? адрес=? терминал =? res=не удалось'
12 апреля 02:10:01 localhost systemd: kubelet.service: основной процесс завершен, код = завершен, статус = 1/FAILURE
12 апреля 02:10:01 localhost systemd: kubelet.service: устройство перешло в состояние сбоя.
12 апреля 02:10:01 localhost systemd: kubelet.service: Ошибка с результатом «код выхода».

@acloudiator Я думаю, вам нужно установить драйвер cgroup в конфигурации kubeadm.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

Затем перезапустите службу kubelet.

Было бы здорово, если бы kubeadm каким-то образом решил проблему конфигурации cgroup.
Идеи:

• Прерывание инициализации в случае неправильной конфигурации
• Заранее проверьте настройки Docker и используйте то, что использует Docker (не уверен в каких-либо последствиях здесь)

Просто обновление, какой бы обходной путь я ни пробовал, он не работал. Поэтому я перешел на CentOS 7.3 для мастера, и он работает как шарм! Я оставил миньонов на CentOS 7.2.

@rushabh268 привет, у меня такая же проблема с Redhat Linux 7.2. После обновления systemd эта проблема решена. Вы можете попробовать обновить systemd перед установкой.
yum update -y systemd
и журнал ошибок от kubelet:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

Я столкнулся с этой проблемой на CentOS 7.3. Проблема исчезла после того, как я удалил docker-ce, а затем установил docker-io.
Я не уверен, что это основная причина. В любом случае, вы можете попробовать, если вышеуказанные методы не работают.

@ZongqiangZhang У меня на узлах установлен докер 1.12.6. @juntaoXie Я также пытался обновить systemd, и он все еще зависает

Итак, я без проблем запускал Centos 7.3 с 1.6.4 на нескольких машинах.

Вы уверены, что отключили selinux?

@timothysc У меня CentOS 7.2, а не CentOS 7.3, и selinux отключен

У меня CentOS Linux версии 7.3.1611 (Core), а KubeAdm 1.6.4 не работает.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

Выход:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr , не могли бы вы поделиться еще немного журналов kube-apiserver ? (те, что в конце вашего комментария)

В строках выше того, что вы уже включили, упоминается один и тот же IP-адрес? Недавно я пытался запустить k8s на двух новых KVM, один с Ubuntu 16.04 и один с CentOS 7.3. Оба дали это:

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

Обратите внимание, что сначала упоминается IP-адрес x.x.x.x , но затем localhost разрешается в y.y.y.y (в моем случае это был общедоступный IP-адрес другого KVM, находящегося на том же физическом сервере). В итоге я смог запустить kubeadm на Ubuntu, но только после установки dnsmasq аналогично https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861. Тот же обходной путь на CentOS не помог.

Это может быть ошибка в kubedns или что-то в этом роде? Интересно, что те же шаги на виртуальных машинах AWS привели к запуску kubeadm. Но экземпляры EC2 слишком дороги для моих личных проектов.

У меня та же проблема, что и у @paulobezerr.

## Версии :
кубелет-1.6.4-0.x86_64
Kubernetes-cni-0.5.1-0.x86_64
кубектл-1.6.4-0.x86_64
кубадм-1.6.4-0.x86_64
докер-клиент-1.12.6-28.git1398f24.el7.centos.x86_64
докер-общий-1.12.6-28.git1398f24.el7.centos.x86_64
докер-1.12.6-28.git1398f24.el7.centos.x86_64

ТАК
uname -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > CentOS Linux, выпуск 7.3.1611 (ядро)

## Шаги:

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## логи API-сервера:
--> 37.247.XX.XXX — общедоступный IP-адрес.

[отдых] 08.06.2017 10:45:19 log.go:30: список [отдых/чванства] доступен по адресу https://37.247.XX.XXX :6443/swaggerapi/
[отдых] 08/06/2017 10:45:19 log.go:30: [отдых/чванство] https://37.247.XX.XXX :6443/swaggerui/ отображается в папку /swagger-ui/
E0608 10:45:19.429839 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Не удалось перечислить *api.Secret: Получить https://localhost : 6443/api/v1/secrets?resourceVersion=0: набрать TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.430419 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось получить список *api.ResourceQuota: получить https://localhost : 6443/api/v1/resourcequotas?resourceVersion=0: набрать TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.430743 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось перечислить *api.ServiceAccount: получить https://localhost : 6443/api/v1/serviceaccounts?resourceVersion=0: наберите TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.431076 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось перечислить *storage.StorageClass: получить https://localhost : 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0: наберите tcp 108.59.253.109:6443:getockopt: в соединении отказано
E0608 10:45:19.431377 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Не удалось перечислить *api.LimitRange: Получить https://localhost : 6443/api/v1/limitranges?resourceVersion=0: наберите TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.431678 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось получить список *rbac.RoleBinding: получить https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: наберите TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.431967 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось перечислить *rbac.ClusterRoleBinding: получить https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0: наберите tcp 108.59.253.109:6443:getockopt: в соединении отказано
E0608 10:45:19.432165 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Не удалось перечислить *api.Namespace: Получить https://localhost : 6443/api/v1/namespaces?resourceVersion=0: наберите tcp 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.432386 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: не удалось перечислить *rbac.ClusterRole: получить https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0: набрать TCP 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.432619 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Не удалось перечислить *rbac.Role: Получить https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0: набрать TCP 108.59.253.109:6443:getockopt: соединение отклонено
I0608 10:45:19.481612 1 serve.go:79] Безопасное обслуживание на 0.0.0.0:6443
W0608 10:45:19.596770 1 storage_extensions.go:127] Не удалось синхронизировать сторонние ресурсы: получить https://localhost :6443/apis/extensions/v1beta1/ ThirdPartyResources: набрать tcp 108.59.253.109:6443: getsockopt: соединение отклонено
E0608 10:45:19.596945 1 client_ca_hook.go:58] Post https://localhost :6443/api/v1/namespaces: наберите tcp 108.59.253.109:6443:getockopt: в соединении отказано
F0608 10:45:19.597174 1 controller.go:128] Невозможно выполнить первоначальную проверку выделения IP-адресов: невозможно обновить блок IP-адресов службы: получить https://localhost :6443/api/v1/services: набрать TCP 108.59.253.109: 6443: getsockopt: в соединении отказано

@albpal У меня была точно такая же проблема неделю назад: dial tcp X.X.X.X показывал нечетный IP-адрес, и я не мог решить эту проблему в CentOS даже после установки dnsmasq и переключения на DNS-серверы Google вместо DNS от моего хостинг-провайдера. Просто из любопытства: можете ли вы проверить, находится ли тот неверный IP-адрес, который вы видите, в том же центре обработки данных, что и ваша виртуальная машина? Вы можете использовать http://ipinfo.io , чтобы оценить это с некоторой степенью уверенности или просто отследить маршрут.

В моем случае неправильный IP-адрес относился к другому KVM на том же физическом сервере. Это может быть связано с DNS на физической машине, для чего может потребоваться обходной путь внутри kube api или kube dns, иначе запуск кластера станет огромной проблемой для многих новичков! Я потратил впустую несколько вечеров, прежде чем заметил dial tcp с неправильным IP-адресом в журналах, что было довольно печальным первым опытом k8s. У моего хостинг-провайдера ( firstvds.ru ) до сих пор нет хорошего готового решения для CentOS KVM.

Что может вызвать это очень странное несоответствие IP-адресов?

@albpal Пожалуйста, откройте новую проблему, то, что вы описали, и то, о чем эта проблема, - это разные проблемы (я думаю, исходя из этой информации)

@kachkaev Я только что проверил, что вы предложили.

Я обнаружил, что неверный IP-адрес заканчивается на CPANEL: vps-1054290-4055.manage.myhosting.com.

С другой стороны, общедоступный IP-адрес моего VPS из Италии, а этот неправильный IP-адрес из США ... так что, несмотря на то, что неправильный IP-адрес имеет что-то связанное с хостингом (CPANEL), похоже, он не относится к другому KVM на тот же физический сервер.

Удалось установить k8s?

@luxas У меня такое же поведение, но я скопировал логи докеравывод тоже.

И /var/log/messages, и вывод kubeadm init такие же, как и исходная проблема.

@albpal , значит, ваша виртуальная машина и эта вторая машина подключены к CPANEL? Хороший знак, потому что тогда мой случай такой же! Тот факт, что это была одна и та же физическая машина, мог быть просто совпадением.

В своих экспериментах я использовал два KVM, один с Ubuntu 16.04, а другой с CentOS 7.3. У обоих была одна и та же проблема с IP-адресом dial tcp . В конце концов я смог запустить kubeadm на Ubuntu, избавившись от DNS-серверов моего провайдера. Решение было основано на совете crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

Это привело к правильному IP-адресу после dial tcp в журналах Ubuntu, и kubeadm инициализировался через пару минут! Я попытался настроить dnsmasq на CentOS таким же образом, но это не решило проблему. Но я абсолютный новичок в этой ОС, так что может быть, я просто забыл перезапустить какую-то службу или почистить какой-то кеш. Попробуйте эту идею!

В любом случае, делать дополнительный шаг по перенастройке DNS кажется неправильным, потому что это очень запутанно (я не специалист по серверам/devops, и все это расследование, которое я провел, чуть не заставило меня плакать :fearful:). Я надеюсь, что kubeadm когда-нибудь сможет определить, работают ли DNS-серверы провайдера странным образом, и автоматически исправить все, что нужно в кластере.

Если кто-то из команды k8s хочет посмотреть, что происходит, я буду рад поделиться корневым доступом к паре новых KVM FirstVDS. Просто напишите мне или DM на Twitter!

Спасибо @kachkaev ! я попробую завтра

cc @kubernetes/sig-network-bugs У вас есть идеи, почему вышеописанное разрешение DNS не работает?

Спасибо @kachkaev , попробуем разобраться. Я не думаю, что это действительно ошибка kubeadm как таковая, но если многие пользователи застряли на одной и той же неправильной конфигурации, мы можем добавить ее в документы по устранению неполадок или около того...

Мои журналы, скорее всего, будут журналами @albpal .
Но я попробую dnsmasq. Спасибо вам всем!

@kachkaev , не работает. Та же проблема 😢
Полный лог прилагается.

лог.txt

Я смог это исправить!! Большое спасибо @kachkaev за подсказки!

Я думаю проблема была в следующем:

### Сценарий:
VPS со следующей схемой конфигурации:

resolv.conf
[ root@apalau ~]# cat resolv.conf
сервер имен 8.8.8.8
сервер имен 8.8.4.4
сервер имен 2001:4860:4860::8888
сервер имен 2001:4860:4860::8844

Поискового домена нет!

хозяева
[ root@apalau ~]# кошка /etc/hosts
127.0.0.1 локальный хост.локальный домен локальный хост
37.XXX.XX.XXX имя.vpshosting.com

Согласно журналам, контейнер kubernetes пытается подключиться к:

Получите https://localhost :6443/api/v1/secrets?resourceVersion=0

И когда я прошу:
$ nslookup "localhost.$(hostname -d)"
IP-адрес, который я получаю, неправильный, то есть 108.59.253.109.

Поэтому я думаю, что эти контейнеры пытаются разрешить локальный хост (без домена) и получают неправильный IP-адрес. Вероятно, потому что «localhost.$(hostname -d)» разрешается в этот IP-адрес, что, я думаю, произойдет практически на любых сервисах VPS.

## Что я сделал, чтобы исправить проблему на VPS CentOS 7.3 (помимо тех шагов, которые показаны на https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm):

Как корень:

1. сброс кубеадм
2. ням установить dnsmasq
3. СР /etc/resolv.conf ~/resolv.conf_bck
4. рм -рф /etc/resolv.conf
5. echo -e "сервер имен 127.0.0.1\nсервер имен $(имя хоста -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. чаттр +i /etc/resolv.conf
8. echo -e "сервер=8.8.8.8\nсервер=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(имя хоста -i)\tlocalhost.$(имя хоста -d)" >> /etc/hosts
10. служба dnsmasq перезапустить
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl перезапустить firewalld
12. инициализация кубеадм

Я добавил имя хоста -i на шаге 5, потому что, если я этого не сделаю, докер добавит 8.8.8.8 в resolv.conf для контейнеров.

Я надеюсь, что это поможет и другим.

Спасибо!!

Рад это слышать @albpal! Я прошел ваши шаги до того, как kubeadm init , и кластер, наконец, инициализировался внутри моего тестового KVM FirstVDS с CentOS 7.3! Единственная дополнительная вещь, которую мне пришлось сделать, это остановить и отключить firewalld, поскольку он блокировал внешние подключения к порту 6443:

systemctl disable firewalld
systemctl stop firewalld

_Я не рекомендую делать это, потому что я не знаю о последствиях - это просто помогло мне выполнить тест на ОС, которую я обычно не использую._

Теперь мне интересно, что можно сделать, чтобы облегчить процесс установки для таких новичков, как я. Путь между застреванием на Created API client, waiting for the control plane to become ready и выяснением ситуации все равно огромен, особенно если принять во внимание время, необходимое для того, чтобы разобраться в этом вопросе и прочитать все комментарии. __Что вы можете предложить?__

@paulobezerr из того, что я вижу в вашем приложении, я считаю, что ваша проблема немного отличается. Мои журналы apiserver содержат что-то вроде:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

в то время как ваши говорят:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(в первом случае это localhost / RANDOM_IP , а во втором случае всегда 10.X.X.X )

К сожалению, я не знаю, что посоветовать, кроме как попробовать разные --apiserver-advertise-address=??? , когда у вас kubeadm init (см. документы ). Мой практический опыт работы с k8s только что достиг 10 дней, большинство из которых были тщетными попытками запустить одноузловой кластер на FirstVDS :-)

Надеюсь, вы разберетесь с этим и поделитесь решением с другими!

@kachkaev Я забыл упомянуть, что применил следующее правило брандмауэра:

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl перезапустить firewalld

Он отлично работает в моей среде, когда применяется это правило без деактивации брандмауэра. Я добавлю его к моему предыдущему комментарию, чтобы собрать все необходимые шаги.

@juntaoXie Спасибо. Обновление версии systemd в соответствии с вашим комментарием сработало для меня.

Все еще получаю эту проблему в течение двух дней, я запускаю все это за прокси-сервером, и, похоже, проблем нет.
kubeadm init зависает в ожидании готовности плоскости управления. Когда я делаю docker ps, контейнеры извлекаются и работают, но порты не выделяются (я не знаю, должно ли это быть, но хорошо). etcd тоже работает нормально. Однако, когда я смотрю на свой сервис kubelet, он говорит, что невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d, который https://github.com/kubernetes/kubernetes/issues/43815 говорит, что все в порядке, вы необходимо применить сеть cni.
Что я и делаю согласно https://www.weave.works/docs/net/latest/kubernetes/kube-addon/. Теперь kubectl говорит, что 8080 был отклонен - ​​вы указали правильный хост или порт? Похоже на проблему курицы и яйца, как мне применить сеть cni, когда мой kubeadm init зависает??? Это так запутанно

Это также не проблема cgroup, и докер, и мой сервис kubelet используют systemd.

FWIW, у меня была такая же проблема на GCP, я пытался использовать Ubuntu 16.04 и CentOS, используя следующие команды в чистом проекте:

$ вычислительные экземпляры gcloud создают test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' узел 1 для тестирования API'

$ вычислительные экземпляры gcloud создают test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' узел 2 для тестирования API'

$ вычислительные экземпляры gcloud создают test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' узел 3 для тестирования API'

$ apt-получить обновление

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-ключ добавить -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl перезапустить кубелет

$ кубеадм инициализация

Итак, после того, как я несколько часов бился с ним головой, я закончил:

$ gcloud beta container --project "weather-177507" кластеры создают "weather-api-cluster-1" --zone "us-west1-a" --username="admin" --cluster-version "1.6.7" --machine-type "f1-micro" --image-type "COS" --disk-size "100" --scopes " https://www.googleapis.com/auth/compute "," https:// www.googleapis.com/auth/devstorage.read_only "," https://www.googleapis.com/auth/logging.write "," https://www.googleapis.com/auth/monitoring.write "," https://www.googleapis.com/auth/servicecontrol "," https://www.googleapis.com/auth/service.management.readonly "," https://www.googleapis.com/auth/trace. добавить " --num-nodes "3" --network "по умолчанию" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

Я смог настроить и запустить кластер там, где не мог, с пустого образа.

Даже я столкнулся с той же проблемой с версией Kubeadm:

он застрял в
[apiclient] Created API client, waiting for the control plane to become ready

Та же проблема, что и у @paulobezerr - моя среда: CentOS 7.4.1708 версия kubeadm: &version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean ", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Компилятор:"gc", Платформа:"linux/amd64"}

Для меня эта проблема не работала с отключенным SELinux. Подсказкой были его шаги, комментарий:

отредактируйте /etc/selinux/config и установите SELINUX=disabled

Шаги установки здесь (https://kubernetes.io/docs/setup/independent/install-kubeadm/) для CentOS говорят:
«Отключение SELinux путем запуска setenforce 0 требуется, чтобы разрешить контейнерам доступ к файловой системе хоста»
но не упоминается (по крайней мере, на вкладке CentOS/RHEL/Fedora), что вы должны отредактировать /etc/selinux/config и установить SELINUX=disabled

Что касается меня, то, несмотря на то, что я запустил setenforce 0, я все равно получал те же ошибки. Редактирование /etc/selinux/config и настройка SELINUX=disabled, а затем перезагрузка исправили это для меня.

Кажется, здесь есть много (потенциально ортогональных) проблем, поэтому я очень хочу, чтобы мы не допустили разногласий. На данный момент мы, кажется, определили 3 проблемы:

1. DNS не может правильно разрешить localhost на некоторых машинах. @kachkaev @paulobezerr Вам удалось это исправить? Мне интересно, как сделать это более явным в наших требованиях, есть идеи?

2. Неверное совпадение cgroup-driver между kubelet и Docker. Мы должны добавить это в наш список требований.

3. SELinux не отключен. Мы должны добавить это в наш список требований.

Как только все три будут рассмотрены с помощью PR, возможно, нам следует закрыть это и позволить людям, которые столкнутся с проблемами в будущем, создавать свои собственные проблемы. Это позволит нам получать более структурированную информацию и предоставлять более детальную поддержку, а не жонглировать множеством вещей в одном потоке. Что вы думаете о @luxas?

Я использовал докер 17.06 (рекомендуется 17.03, но недоступен на docker.io) и столкнулся с той же проблемой. Обновление до 17.09 волшебным образом устранило проблему.

Поскольку эта ветка такая длинная и, вероятно, есть много совершенно разных проблем, самое продуктивное, что я могу добавить, помимо отличного комментария @jamiehannaford , это то, что, пожалуйста, открывайте новые, целевые проблемы со всеми соответствующими журналами / информацией на случай, если что-то терпит неудачу _с новейшей версией kubeadm v1.8_, которая автоматически определяет ошибочное состояние намного лучше, чем более ранние версии. Мы также улучшили нашу документацию по требованиям и пограничным случаям, что, как мы надеемся, сэкономит людям время.

Спасибо всем!

у меня была такая же проблема с 1.8 в CENTOS 7 с 1.8? у кого была такая же проблема или кто знает как исправить.

@rushins Если вы хотите получить помощь по возможной проблеме, которую вы видите, откройте новую проблему здесь с достаточными подробностями.

У меня та же проблема, что и у @rushabh268 , которая равна connection refused , а не localhost:6443/api .
В конце концов я решил это, заметив домен, ищущий search xxx.xx.xxxx.org .

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Окружение:
-> CentOS-7-x86_64-минимальный-1708
-> К8с v1.9.2
-> Докер v17.12.0.ce
-> в частной сети xxx.xx.xxxx.org

Пожалуйста, ради бога, добавьте это в документы. Я пытался настроить свой кластер в течение многих ночей после работы под предлогом «развлечься и поиграть с технологиями». Меня погубило то, что главный узел не получил правильный IP-адрес при запуске nslookup localhost.

Спасибо @kachkaev за решение.