Я могу успешно установить Kubernetes на сервер Ubuntu 16 и перевести главный узел в состояние «Готов». Но если я перезагружаюсь / перезапускаю, я получаю сообщение об ошибке в заголовке, когда пытаюсь использовать KUBECTL.
Нужно ли мне вводить следующие команды, данные при первоначальном запуске KUBEADM INIT в мой профиль, чтобы сохранить?
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Я следовал рецепту в Поваренная книга O'Reilly Kubernetesвместе с использованием документации Google K8S и Serverfault.
Я могу успешно запустить все системные модули, и я могу успешно запустить как мастер, так и один рабочий как Ready. Но они не сохраняются после перезагрузки.
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-k8s-master 1/1 Running 0 1m
kube-system kube-apiserver-k8s-master 1/1 Running 0 2m
kube-system kube-controller-manager-k8s-master 1/1 Running 0 2m
kube-system kube-dns-86f4d74b45-phphd 3/3 Running 0 3m
kube-system kube-proxy-25mtq 1/1 Running 0 3m
kube-system kube-scheduler-k8s-master 1/1 Running 0 2m
kube-system weave-net-rfb6z 2/2 Running 0 50s
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 9m v1.10.3
k8s-worker1 Ready <none> 14s v1.10.3
Прежде всего проверьте, запущен ли ваш кластер:
$ ps aux | grep apiserver
$ ps aux | grep etcd
$ docker ps
Вы должны увидеть все необходимые процессы Kubernetes, работающие как kube-proxy, kube-apiserver, kube-controller-manager, kube-scheduler, etcd.
Если кластер готов, вы можете попытаться получить доступ kube-apiserver с помощью kubectl инструмент.
По умолчанию, kubectl берет свою конфигурацию из файла $HOME/.kube/config
Поведение по умолчанию можно изменить, установив переменную среды KUBECONFIG.
В kubectl прочитать все файлы конфигурации, перечисленные в этой переменной, и объединить их параметры конфигурации.
Таким образом, вы можете сохранить конфигурацию нескольких кластеров в отдельных файлах для упрощения обслуживания.
В этом случае следует установить KUBECONFIG переменная в профиле пользователя, чтобы убедиться, что она имеет правильное значение после следующего входа в систему.
Другой способ использовать конкретный файл конфигурации - установить --kubeconfig аргумент в командной строке
$ kubectl --kubeconfig config_file_path <other_command_line_arguments>
Вы можете проверить доступную конфигурацию (конфиденциальная информация будет подавлена), выполнив следующую команду:
# kubectl config view
Есть возможность настроить несколько контекстов в одном файле конфигурации и переключить контекст, указав его имя в командной строке. Это полезно, если вы управляете несколькими кластерами (или разными учетными записями служб для одного кластера), используя одну и ту же учетную запись пользователя.
$ kubectl config --kubeconfig=config-demo use-context exp-scratch <other_command_line_arguments>
Проверьте документация для подробностей.
Когда вы создаете кластер командой kubeadm init , он добавляет конфигурацию подключения для kubectl в файл /etc/kubernetes/admin.conf
-rw------- 1 root root 5446 May 1 11:11 admin.conf
Вы можете указать это как kubectl config напрямую, если вы используете учетную запись root.
Чтобы использовать его с другой учетной записью пользователя, вам необходимо скопировать его в пользовательский $HOME/.kube/config файл и сделать его доступным для пользователя.
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Достаточно сделать это только один раз для каждой учетной записи пользователя, которую вы планируете использовать для управления кластером. Это обычный файл, и он не исчезает после перезагрузки, поэтому вы все равно сможете получить доступ к запущенному кластеру Kubernetes. kubectl команда.
Если вы сбросите кластер с помощью kubeadm reset и создать его снова, вам нужно обновить kubectl конфигурация подключения в профиле пользователя, поскольку предыдущие учетные данные кластера не будут работать с новым кластером.
Я не проверял журналы. Ubuntu 16.04 ведет журналы через systemd, поэтому, когда я не забыл проверить журналы через journalctl, сразу стало ясно, что Kubernetes жаловался на то, что своп включен. При первоначальной установке я отключил подкачку на каждом сервере, но я не изменил / etc / fstab, чтобы отключить подкачку навсегда.