k8sВсе соответствующие конфигурации серии упражнений находятся вgithub：https://github.com/huangguisu/k8s.git

1. Планирование архитектуры развертывания и подготовка среды.

1. Выбор способа установки

На данный момент существует три способа установки

Первый — установка yum

Преимущество использования yum для установки в том, что это просто. Недостаток в том, что для получения последней версии вам необходимо узнать исходный код yum, и вы не можете самостоятельно указать зависимости всего программного обеспечения. Особенно при сравнении версий системы. версия kubernetes, установленная с использованием исходного кода yum, также будет ограничена.

Первый — бинарная установка

Установка с использованием двоичных файлов,Преимущество в том, что вы можете установить любую версию kubernetes.,Недостаток – более сложная конфигурация.。Хотя метод установки бинарного установочного пакета более трудоемкий, бинарная установка облегчает ознакомление с каждым компонентом и очень полезна для изучения k8s. Поэтому все наши руководства представляют собой бинарную установку.

Третий способ — установка kubeadm

kubeadm — это официально предоставляемый Kubernetes инструмент для быстрой установки кластеров Kubernetes. Он устанавливает каждый компонент k8s в докер и запускает его как контейнер. По мере выпуска каждой версии Kubernetes она будет обновляться одновременно. kubeadm будет корректировать некоторые методы настройки кластера. Экспериментируя с kubeadm, вы можете узнать некоторые новые рекомендации по настройке кластера от официальных лиц Kubernetes.

2. Скачать версию

https://github.com/kubernetes/kubernetes/releases

Выберите соответствующую версию по URL-адресу выше и загрузите двоичный файл со страницы CHANGELOG. В этой статье в качестве примера используется версия 1.14.1.

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#v1142

Выберите kubernetes-server-linux-amd64.tar.gz в служебных двоичных файлах.

Этот файл уже содержит все компоненты, необходимые для работы K8S. Нет необходимости отдельно скачивать такие компоненты, как Клиент.

После декомпрессии,существоватьkubernetes/server/bin Путь содержит некоторые необходимые компоненты:

Установите переменные среды, чтобы облегчить прямое использование команд Kubernetes:

export K8S_BIN=/mnt/app/kubernetes/server/bin/ export PATH="

3. Планирование узла и подготовка среды

k8s требует как минимум одного мастера и одного узла для формирования работоспособного кластера. Мы построим главный узел и 2 узла узла.

У нас три сервера. План такой. Лучше всего модифицировать хосты.

192.168.10.21 k8s-master

192.168.10.22 k8s-node1

192.168.10.23 k8s-node2

1. Измените файл /etc/hosts и добавьте разрешение доменного имени, чтобы облегчить последующее использование.

cat <<EOF >>/etc/hosts
192.168.10.21  k8s-master
192.168.10.22  k8s-node1
192.168.10.23  k8s-node1
192.168.10.21 node1.etcd.k8-cluster.com
192.168.10.22 node2.etcd.k8-cluster.com
192.168.10.23 node3.etcd.k8-cluster.com
EOF

2. Отключаем фаервол, селинукс и свап.

systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i "s/^SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config
#Закрытьсвоп
swapoff -a
#Чтобы навсегда отключить раздел подкачки, закомментируйте строку подкачки в файле /etc/fstab
sed -i 's/.*swap.*/#&/' /etc/fstab

4. Подготовьте сертификат:

Конкретные инструкции：k8s Practice (8) — конфигурация аутентификации безопасности SSL

Соответствующие сертификаты размещены по адресу:/mnt/app/kubernetes/ssl/.

mkdir /mnt/app/kubernetes/ssl/

cat <<EOF >> /mnt/app/kubernetes/ssl/masterssl.cnf

req

req_extensions = v3_req

distinguished_name = req_distinguished_name

req_distinguished_name

v3_req

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

alt_names

DNS.1 = kubernetes

DNS.2 = kubernetes.default

DNS.3 = kubernetes.default.svc

DNS.4 = kubernetes.default.svc.cluster.local

DNS.5 = master.k8s.tulingapi.com

DNS.6 = k8s-master

IP.4 = 127.0.0.1

IP.1 = 192.168.10.21

IP.2 = 192.168.0.1

IP.3 = 10.0.0.1

IP.4 = 172.17.0.1

IP.4 = 172.16.0.1

IP.4 = 172.18.0.1

EOF

#rootcertificate

openssl genrsa -out ca-private.pem 2048

openssl req -x509 -new -nodes -key ca-private.pem -days 3650 -out ca-public.pem -subj "/CN=kube-ca"

#apiservercertificate

openssl genrsa -out apiserver-private.pem 2048

openssl req -new -key apiserver-private.pem -out apiserver.csr -subj "/CN=k8s-master" -config masterssl.cnf

openssl x509 -req -in apiserver.csr -CA ca-public.pem -CAkey ca-private.pem -CAcreateserial -out apiserver-public.pem -days 3650 -extensions v3_req -extfile masterssl.cnf

#Устанавливаем клиентский сертификат kube-controller-manager

openssl genrsa -out manager-client-private.pem 2048

openssl req -new -key manager-client-private.pem -subj "/CN=k8s-master" -out manager-client.csr

openssl x509 -req -in manager-client.csr -CA ca-public.pem -CAkey ca-private.pem -CAcreateserial -out manager-client-public.pem -days 5000

#node создание двустороннего сертификата клиента узла

openssl genrsa -out kubelet-private.pem 2048

openssl req -new -key kubelet-private.pem -out kubelet.csr -subj "/CN=kubelet-key"

openssl x509 -req -in kubelet.csr -CA ca-public.pem -CAkey ca-private.pem -CAcreateserial -out kubelet-public.pem -days 3650

2. Установка высокодоступного главного узла Kubernetes.

​

Компоненты, включенные в главный узел Kubernetes.

• kube-apiserver
• kube-scheduler
• kube-controller-manager

kube-scheduler、kube-controller-manager и kube-apiserver Функции этих трех компонентов тесно связаны, поэтому рекомендуется развертывать эти три компонента на одной машине. Одновременно может быть только один kube-scheduler、kube-controller-manager Процесс находится в рабочем состоянии. Если запущено несколько процессов, один из них необходимо выбрать путем выборов. leader；

Службы Kubernetes завершаются прямым запуском двоичных файлов и добавлением параметров запуска. Для облегчения управления распространенными практиками являются:

1. Вы можете использовать nohup для запуска двоичных файлов для обеспечения фоновой работы.

2. Настройте процесс службы Kubernetes в качестве системного сервера.

3. Используйте супервизор для управления. Мы все здесь используем этот метод.

2.1、Kuber-apiserver

2.1.1 Обзор API-сервера Kubernetes

Kubernetes API Основная функция сервера — предоставлять HTTP для добавления, удаления, изменения, запроса и просмотра различных объектов ресурсов Kubernetes (таких как Pod, RC, Service и т. д.). Restинтерфейс,Станьте центральным узлом для взаимодействия данных и связи между различными функциональными модулями в кластере.,Это шина данных и центр обработки данных всей системы. кроме,Он также имеет следующие характеристики:

1. Это вход API для управления кластером;
2. Это вход в управление квотами ресурсов;
3. Обеспечить полный механизм безопасности кластера;

2.1.2 Запуск службы процесса Kube-apiserver

Kubernetes API Server предоставляет услуги через процесс Kube-apiserver, который выполняется на главном узле. По умолчанию процесс kube-apiserver предоставляет службы REST на порту 8080 локального компьютера (соответствует параметру --insecure-port).

Простой в использованииnohupзапускать,Потому что мой локальный порт 8080 занят.,Исправлятьkube-apiserver порт: 9090.

nohup /mnt/app/kubernetes/server/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=9090 --etcd-servers=http://node1.etcd.k8-cluster.com:2379 --service-cluster-ip-range=192.168.10.0/16 --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota --logtostderr=false --log-dir=/mnt/logs/k8s-kube-apiserver/ --v=2 &

Сервер, к которому по умолчанию подключается команда kubectl. Это http://localhost:8080. Поскольку номер порта был изменен, вам необходимо указать сервер. Вы можете использовать псевдоним. изменить: alias kubectl=" kubectl -s http://localhost:9090" echo alias kubectl=" kubectl -s http://localhost:9090" >> ~/.bashrc

Мы также можем включить безопасный порт HTTPS (--secure-port=6443), чтобы активировать механизм безопасности и повысить безопасность доступа к REST API.

Если кластер хочет иметь возможность публиковать модули, его необходимо запустить с использованием SSL-аутентификации:

nohup /mnt/app/kubernetes/server/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=9090 --etcd-servers=http://node1.etcd.k8-cluster.com:2379 --service-cluster-ip-range=192.168.10.0/16 --service-account-key-file=/mnt/app/kubernetes/ssl/apiserver-private.pem --client-ca-file=/mnt/app/kubernetes/ssl/ca-public.pem --tls-private-key-file=/mnt/app/kubernetes/ssl/apiserver-private.pem --tls-cert-file=/mnt/app/kubernetes/ssl/apiserver-public.pem --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota --logtostderr=false --log-dir=/mnt/logs/k8s-kube-apiserver/ --v=2 &

Используйте управление супервизором: https://github.com/huangguisu/k8s/tree/master/supervisor/k8s-kube-apiserver.conf

2.1.3 Описание параметров конфигурации:

Общие параметры: –admission-control="AlwaysAdmit": Допуск ресурсов в кластере. Упорядоченный список плагинов контроллера, разделенных запятыми, AlwaysAdmit, –admission-control-config-file=””: Admission Файл конфигурации контроллера. –advertise-address=<nil>: API трансляции IP-адреса, предоставленные Сервером всем членам кластера. Другие кластеры могут получить доступ к этому IP-адресу. Если он пуст, будет использоваться --allow-privileged=false:. true, что указывает на то, что привилегированные контейнеры разрешены. –authorization-mode=”AlwaysAllow”: Упорядоченный список плагинов авторизации безопасного порта, разделенных запятыми, AlwaysAllow, AlwaysDeny, ABAC-authorization-policy-file="": CSV-файл политики авторизации, используемый для настройки режима –authorization-mode=ABAC. –basic-auth-file=””: Если этот параметр настроен, этот файл разрешит API через базовую аутентификацию HTTP. Запрос безопасного порта сервера. –bind-address=0.0.0.0: Service –read-only-port и –secure-port IP-адрес порта. Соответствующим интерфейсом должны быть другие кластеры через CLI/web Guest –cert-dir="/var/run/kubernetes": Каталог сертификатов TLS (по умолчанию /var/run/kubernetes). Если настроено –tls-cert-fileи –tls—client-ca-file="": Если этот параметр установлен, любой запрос на отправку сертификата клиента будет проверять подлинность с помощью CommonName связанного сертификата клиента. Сертификат клиента: –cloud-config="": Путь к файлу конфигурации поставщика облачных услуг Пустой означает, что такого файла конфигурации нет. –cloud-provider=””: Поставщик облачного сервиса. Если поле пусто, это означает, что такого поставщика нет. –cluster-name=”kubernetes”: Префикс экземпляра кластера. –cors-allowed-origins=[]: CORS разрешенные источники (разрешенные origins, Список переводов, которые следует учитывать, через запятую. Разрешенное происхождение может быть Параметры ETCD: –etcd-config=””: Файл конфигурации клиента ETCD является взаимоисключающим с элементом конфигурации -etcd-servers. –etcd-prefix=”/registry”: Префикс всех путей к ресурсам в ETCD. –etcd-servers=[]: Список серверов ETCD (http://ip:port), разделенных запятыми. Взаимоисключается с элементом конфигурации -etcd-config. –etcd-servers-overrides=[]: Файлы покрытия сервера ETCD для каждого ресурса, разделенные запятыми. Независимый формат покрытия, группа/ресурс#серверы, серверы Другие параметры; –event-ttl=1h0m0s: Значение времени сохраняемого события, по умолчанию — 1 час. –experimental-keystone-url=””: Если пройдено, активируйте плагин аутентификации Keystone. –external-hostname=””: Имя хоста, используемое для создания внешних URL-адресов для мастера. –google-json-key=””: ПользовательGoogle Cloud Platform Service Account JSON Ключевая аутентификация. –insecure-bind-address=127.0.0.1: IP-адрес службы незащищенного порта (для всех интерфейсов установлено значение 0.0.0.0). По умолчанию используется локальный адрес. –insecure-port=8080: Небезопасный и неаутентифицированный порт доступа к процессу, по умолчанию 8080. Предположим, что правило брандмауэра устанавливает блокировку порта за пределами кластера, а в –kubelet-certificate-authority="": Путь сертификации. Файл центра сертификации. –kubelet-client-certificate=””: Путь к файлу сертификата клиента TLS. –kubelet-client-key=””: Путь к файлу ключей клиента TLS. –kubelet-https=true: Используйте https для установки соединения Kubelet. –kubelet-port=10250: Кубелет порт. –kubelet-timeout=5s: Значение тайм-аута операции Kubelet. –log-flush-frequency=5s: Максимальное количество секунд буферизации журнала. –long-running-request-regexp=”(/|^)((watch|proxy)(/|)|(logs?|portforward|exec|attach)/? )”: Длинное совпадение –master-service-namespace="default": Namespace, основной сервис Kubernetes этого пространства имен должен быть внедрен в Pod. –max-connection-bytes-per-sec=0: Если ненулевое значение, представляет максимальное количество подключений для каждого пользователя в байтах/секунду, которое в настоящее время применимо только к длительным запросам. –max-requests-inflight=400: Максимальное количество запросов, выполняемых в течение заданного периода времени. Если максимальное значение превышено, запрос будет отклонен. Ноль означает отсутствие ограничений. –min-request-timeout=1800: Это необязательное поле, в котором указывается минимальное время обработки запроса в секундах. Этот запрос должен быть активен до истечения времени ожидания –oidc-ca-file="": Если эта опция установлена, соответствующие органы в файле Oidc-ca проверят сертификат службы OpenID. В противном случае используется корневой сертификат хоста. –oidc-client-id=””: Если поле oidc-issuer-url установлено, это поле и идентификатор клиента подключения OpenID также должны быть установлены. –oidc-issuer-url=””: URL-адреса, выданные OpenID, принимают только протокол HTTPS. Если это поле установлено, оно будет использоваться для проверки OIDC. JSON Web Token（JWT）–oidc-username-claim=”sub”: . Значения, отличные от значения по умолчанию, могут быть неуникальными и изменяемыми. Этот флаг все еще находится на стадии тестирования. Подробную информацию см. в разделе Аутентификация. –profiling=true: Анализ через веб-интерфейс host:port/debug/pprof/。 –runtime-config=: Набор пар ключ-значение ключ=значение, описывающих конфигурацию среды выполнения, также будет передан обратно на API-сервер. APIS/key используется для включения –secure-port=6443: Аутентификация и авторизация по HTTPS. 0 означает, что служба HTTPS не поддерживается. –service-account-key-file=””: Этот файл содержит закодированные в RPM x509 Закрытый ключ и открытый ключ RSA, используемые для проверки токена ServiceAccount. --service-account-lookup=false: true, Обозначает службу проверки Токен учетной записи включен в ETCD как часть аутентификации. –service-cluster-ip-range=: Диапазон IP-адресов с тегом CIDR, из которого IP-адреса назначаются кластерам служб. Этот диапазон не может соответствовать ни одному диапазону IP-адресов, назначенному узлу Pod –service-node-port-range=: Диапазон портов для службы видимости NodePort, включая оба конца диапазона. Например, '30000-32767', включая 30000и32767–ssh-keyfile="": Если не пусто, используйте безопасный агент SSH для узла и используйте файл ключа. –ssh-user=””: Если не пусто, используйте безопасный агент SSH для этого узла, используя это имя пользователя. –storage-versions=”extensions/v1beta1,v1″: Сохраняет версию ресурса. Разные группы хранятся в разных версиях, укажите формат "group1/version1,--tls-cert-file="": Этот файл содержит сертификат x509 для HTTPS. (Сертификат CA, если он присутствует, подключается после сертификата сервера). Если служба HTTPS поддерживается и параметр –tls-private-key-file="" недоступен: Этот файл содержит совпадение закрытого ключа x509 –tls-cert-file. –token-auth-file=””: Этот файл использует проверку токена для защиты API. Защищенный порт сервера. –watch-cache=true: Доступно в API Сервер проверяет кеш.

2.1.4 Использование API-сервера Kubernetes

Обычно мы можем взаимодействовать с API-сервером Kubernetes через инструмент командной строки kubectl, а интерфейсом между ними является вызов REST. Вы также можете использовать инструмент командной строки Curl для быстрой тестовой проверки.

Просмотр информации о версии Kubernetes API

curl k8s-master:9090/api

Просмотр типов объектов ресурсов, которые в настоящее время поддерживаются API-сервером Kubernetes.

curl k8s-master:9090/api/v1

Просмотр различной информации о списке ресурсов:

curl k8s-master:9090/api/v1/pods

curl k8s-master:9090/api/v1/services

curl k8s-master:9090/api/v1/replicationcontrollers

2.1.5 Интерфейс узла управления Kubernetes-Proxy API

Функция этого типа интерфейса заключается в прокси-запросах REST, то есть API-сервер kubernetes перенаправляет полученные запросы REST на порт REST демона kubelet на определенном узле, а за ответ отвечает процесс kubelet.

Соответствующий интерфейс для управления узлом в Kubernetes Proxy API. Путь REST этого интерфейса — /api/v1/proxy/nodes/{name}, где имя — это имя узла или IP-адрес, включая следующие конкретные интерфейсы:

• /api/v1/proxy/nodes/{name}/pods　#Список информации обо всех модулях в обозначенном узле
• /api/v1/proxy/nodes/{name}/stats #Список статистической информации о физических ресурсах в узле
• /api/v1/proxy/nodes/{name}/spec #List сводная информация об обозначенных узлах

Пример: имя узла — k8s-node-1. Следующая команда получает все запущенные модули на узле:

• curl localhost:8080/api/v1/proxy/nodes/k8s-node-1/pods

Следует отметить, что полученные здесь информационные данные о модулях поступают из Node, а не из базы данных etcd, поэтому в определенные моменты времени они могут отличаться. Кроме того, если процесс kubelet содержит --enable-debugging-handles=true, когда он находится в Qidong, API прокси-сервера namekubernetes также добавит следующий интерфейс:

• /api/v1/proxy/nodes/{name}/run #Запускаем контейнер на узле
• /api/v1/proxy/nodes/{name}/exec #Запуск команды в контейнере узла
• /api/v1/proxy/nodes/{name}/attach #Прикрепляем контейнер к узлу
• /api/v1/proxy/nodes/{name}/portForward #Реализовать переадресацию портов модуля на узле
• /api/v1/proxy/nodes/{name}/logs #Выводит различную информацию журналов узлов, такую ​​как Tallylog, Lastlog, wtmp, ppp/, rhsm, Audit, Tuned, иanaconda и т. д.
• /api/v1/proxy/nodes/{name}/metrics #Перечислите информацию о метриках, относящуюся к узлу
• /api/v1/proxy/nodes/{name}/runningpods #Список информации о запущенном модуле на узле
• /api/v1/proxy/nodes/{name}/debug/pprof #Перечислить статус текущего веб-сервиса на узле, включая использование ЦП и памяти

Связанные интерфейсы Pod в Kubernetes Proxy API. Через эти интерфейсы мы можем получить доступ к сервисам, предоставляемым контейнером в модуле (например, к сервисам, предоставляемым Tomcat по адресу 8080).

• /api/v1/proxy/namespaces/{namespace}/pods/{name}/{patch:*} #Доступ к определенному сервисному интерфейсу модуля
• /api/v1/proxy/namespaces/{namespace}/pods/{name} Модуль #Access
• /api/v1/proxy/namespaces/{namespace}/pods/{name}/proxy/{patch:*} #Доступ к сервисному интерфейсу модуля
• /api/v1/proxy/namespaces/{namespace}/pods/{name}/proxy #Модуль доступа

Среди вышеупомянутых 4 интерфейсов,Функции последних двух интерфейсов точно такие же, как и первых двух.,Только написание другое.

2.1.6 интерфейс прокси-сервера kube-proxy

Если мы хотим предоставить внешнему миру только часть службы REST, мы можем запустить внутренний прокси, запустив процесс kube-proxy на главном или любом другом узле.

Выполнив следующую команду, мы запускаем прокси на порту 8001 и запрещаем клиенту доступ к API RC:

• kubectl proxy --reject-paths=“^/api/v1/replicationcontrollers” --port=8001 --v=2

Проверьте с помощью следующей команды:

• curl localhost:8001/api/v1/replicationcontrollers

Прокси-сервер kubectl имеет множество функций. Одна из наиболее практичных функций — предоставление простого и эффективного механизма безопасности. Например, при использовании белого списка для ограничения несанкционированного доступа клиентов просто используйте следующие параметры:

• --accept-host=“^localhost,^127\\.0\\.0\\.1 ,^\::1\

Последний способ — вызвать API-сервер Kubernetes с помощью b-программирования. Конкретные сценарии использования подразделяются на следующие два типа:

Первый сценарий использования: пользовательский процесс, запущенный в Pod, вызывает API Kubernetes, который обычно используется для достижения цели построения распределенного кластера. Откуда процесс в Pod знает адрес доступа к API-серверу? Поскольку API-сервер Kubernetes сам по себе также является службой, его имя — Kubernetes, его адрес кластера — это первый IP-адрес в пуле адресов ClusterIP, а порт, который он обслуживает? это HTTPS-порт 443. Это можно подтвердить с помощью kubectl get svc.

Второй сценарий использования: разработка платформы управления на базе Kubernetes. Например, вызов Kubernetes API Для завершения графического создания и управления объектами ресурсов, такими как Pod, Service и RC, вы можете использовать различные языковые версии Client, предоставляемые Kubernetes и различными сообществами с открытым исходным кодом для разработчиков. Library。

2.1.7 Связь между функциональными модулями кластера

Каждый функциональный модуль в кластере использует API Информация о сервере хранится в etcd. Когда необходимо получить и обработать эти данные, используется API. Интерфейс REST, предоставляемый Сервером (с использованием метода GET/LIST/WTCH), реализован для реализации информационного взаимодействия между модулями;

процесс kubelet и API Взаимодействие с сервером:каждыйnodeнаkubeletкаждый второй период времени,будет вызван один разAPI Интерфейс REST сервера сообщает о своем собственном статусе, API После получения этой информации Сервер обновляет информацию о каждом узле в etcd.

   Кроме того, kubelet также использует API Serverизwatchинтерфейс监听podинформация,Если вы слышите, что к этому узлу планируется привязать новую копию Pod,Затем выполните логику создания контейнера, соответствующего поду, если он обнаружит, что объект пода удален;,Затем удалите соответствующий контейнер Pod на этом узле, если информация о Pod Исправлять отслеживается;,Затем kubelet следит за изменениями,Он будет соответствовать Pod-контейнеру этого узла.

Процесс и API kube-controller-manager Взаимодействие с сервером:kube-controller-manager中изNode Модуль контроллера через API Интерфейс Watch, предоставляемый Сервером, отслеживает информацию узла в режиме реального времени и обрабатывает ее соответствующим образом;

kube-планировщик и API Взаимодействие с сервером:когдаschedulerпроходитьAPI После того, как интерфейс наблюдения сервера отслеживает информацию о вновь созданной копии пода, он получает список всех узлов, которые соответствуют требованиям пода, начинает выполнять логику планирования пода и привязывает под к целевому узлу после завершения планирования. успешный. Чтобы облегчить воздействие API на каждый модуль кластера Давление сервера: каждый функциональный модуль использует механизм кэширования для кэширования данных. Каждый функциональный модуль периодически считывает данные из API Сервер получает информацию об указанном объекте ресурса (через LIST или просмотр), а затем сохраняет эту информацию в локальном кэше. В некоторых случаях функциональный модуль не имеет прямого доступа к API. Сервер, но косвенно обращается к API, обращаясь к кэшированным данным. Server

2.2、Kuber-controller-manager

Kube-controller-manager обрабатывает обычные фоновые задачи в кластере. Если APIServer выполняет фронтенд-работу, то за фон отвечает диспетчер контроллеров. Каждый ресурс соответствует контроллеру. Менеджер управления отвечает за управление этими контроллерами и поддержание состояния кластера, например, обнаружение ошибок, автоматическое расширение, периодические обновления и т. д. Например, мы создаем Pod через APIServer. Когда Pod успешно создан, APIServer; задача выполнена.

Запустите Kube-controller-manager, опираясь на kube-apiserver (--master=http://k8s-master:9090):

nohup kube-controller-manager --master=http://k8s-master:9090 --logtostderr=false --log-dir=/mnt/logs/k8s-kube-controller-manager/ --v=2 &

Основные параметры конфигурации Kube-контроллера-менеджера:

--master: указать URL-адрес API-сервера

--logtostderr=false: установите значение false, чтобы записать журнал в файл, в противном случае это будет stderr.

--log-dir=/mnt/logs/k8s/: каталог журналов

--v=2: уровень журнала

Приведенная выше команда запуска относительно проста.,из-за выпускаpodи другие необходимые ресурсыПроверка безопасности, поэтому требуется https.

оKubernetesБезопасность： https://guisu.blog.csdn.net/article/details/95067232 иsslСертификат：https://cloud.tencent.com/developer/article/1981384

Используйте управление супервизором: https://github.com/huangguisu/k8s/tree/master/supervisor/k8s-kube-controller-manager.conf

Запуск Supervisor является результатом финальной версии кластера:

[program:k8s-kube-controller-manager]
[program:k8s-kube-controller-manager]
command =/mnt/app/kubernetes/server/bin/kube-controller-manager --master=https://k8s-master:6443 --cluster-cidr=10.0.0.0/16 --service-account-private-key-file=/mnt/app/kubernetes/ssl/apiserver-private.pem  --root-ca-file=/mnt/app/kubernetes/ssl/ca-public.pem  --cluster-signing-cert-file=/mnt/app/kubernetes/ssl/ca-public.pem  --cluster-signing-key-file=/mnt/app/kubernetes/ssl/ca-private.pem --kubeconfig=/mnt/app/kubernetes/ssl/kubeconfig.yaml   --logtostderr=false --log-dir=/mnt/logs/k8s-kube-controller-manager/  --v=2
process_name=%(program_name)s
numprocs=1
directory=/mnt/app/kubernetes/
user=root
stdout_logfile=/mnt/logs/%(program_name)s/server.log
stderr_logfile=/mnt/logs/%(program_name)s/error.log
serverurl=AUTO = /mnt/logs/k8s-kube-apiserver/error.log

2.3、Kuber-scheduler

Расписание планирует размещение модуля на соответствующем узле узла в соответствии с заранее определенной политикой планирования. Если планировщик рассматривается как черный ящик, то его входные данные — это модуль и список нескольких узлов, а его выходные данные — привязка модуля и узла. Kubernetes в настоящее время предоставляет алгоритмы планирования, а также сохраняет интерфейсы. Пользователи определяют свои собственные алгоритмы планирования в соответствии со своими потребностями.

Запустите kube-scheduler, который зависит от kube-apiserver (--master=http://k8s-master:9090):

nohup kube-scheduler --master=http://k8s-master:9090 --logtostderr=false --log-dir=/mnt/logs/k8s-kube-scheduler/ --v=2 &

Проверьте, успешно ли установлен Мастер

$ kubectl get componentstatuses

Используйте управление супервизором:

[program:k8s-kube-scheduler]
command =/mnt/app/kubernetes/server/bin/kube-scheduler --master=http://k8s-master:9090 --address=0.0.0.0  --logtostderr=false --log-dir=/mnt/logs/k8s-kube-scheduler/  --v=2
process_name=%(program_name)s
numprocs=1
directory=/mnt/app/kubernetes/
umask=022
priority=999
autostart=true
autorestart=true
startsecs=10
startretries=3
exitcodes=0,2
stopsignal=QUIT
stopwaitsecs=10
user=root
redirect_stderr=true
stdout_logfile=/mnt/logs/%(program_name)s/server.log
stdout_logfile_maxbytes=50000MB
stdout_logfile_backups=10
stdout_capture_maxbytes=0MB
stdout_events_enabled=false
stderr_logfile=/mnt/logs/%(program_name)s/error.log
stderr_logfile_maxbytes=1MB
stderr_logfile_backups=10
stderr_capture_maxbytes=1MB
stderr_events_enabled=false
;environment=JAVA_HOME="/usr/java"
serverurl=AUTO = /mnt/logs/k8s-kube-apiserver/error.log

3. Узел узла

Каждый узел Node в основном состоит из четырех шаблонов: kublet, kube-proxy, docker, flanneld.

kube-scheduler также зависит от kube-apiserver

На рабочем узле сначала установите docker и запустите демон docker.

Скопируйте kubernetes-server-linux-amd64.tar.gz на все серверы узлов и извлеките его в: /mnt/app/kubernetes/

Установите переменные среды:

export K8S_BIN=/mnt/app/kubernetes/server/bin/ export PATH="

1 сервис кубекета

kublet — агент Мастера на каждом узле Node.,Это самый важный модуль на узле Node.,Он отвечает за обслуживание и управление всеми контейнерами на узле.,А вот если контейнер создан не через kubernetes,Это не удается. По сути,Он отвечает за соответствие рабочего состояния модуля желаемому состоянию.

Кублет запускается на каждом рабочем узле, получает запросы, отправленные kube-apiserver, управляет контейнерами Pod и выполняет интерактивные команды, такие как exec, run, logs и т. д.;

kublet автоматически при запуске kube-apiserver Регистрация информации об узле, встроенная cadvisor Статистика и мониторинг использования ресурсов узлов;

В целях обеспечения безопасности этот документ открыт только для получения https 请求из Безопасность端口,Аутентификация и авторизация запросов,Запретить несанкционированный доступ (например, через API-сервер, Хипстер).

Официальная рекомендация заключается в том, что мы используем--configобозначение Конфигурационный файл,并существовать Конфигурационный файл中обозначение Оказывается, этиflag所Конфигурацияиз内容。Подробности можно посмотретьздесьSet Kubelet parameters via a config file。Это такжеKubernetesДля поддержки динамическогоKubeletКонфигурация（Dynamic Kubelet Configuration）才这么做из,ссылкаReconfigure a Node’s Kubelet in a Live Cluster。

Файл конфигурации kubelet должен быть в формате json или yaml.,Подробности можно посмотретьздесь。

Kubernetes 1.8 начинает требовать отключения системного Swap. Если его не отключить, kubelet не сможет запуститься в конфигурации по умолчанию. Метод Swap для выключения системы следующий:

swapoff -a

Исправлять /etc/fstab файл, закомментировать SWAP из自动挂载,использоватьfree -mподтверждатьswapУже закрыто。 Чтобы настроить параметр swappiness, добавьте следующую строку в Исправлять/etc/sysctl.d/k8s.conf:

vm.swappiness=0

Из Кубернетеса 1.10 Динамический запуск Kubelet Функция конфигурации переходит в стадию бета-тестирования,kubeletиз大多数命令行параметр都改为推荐существовать--configобозначение位置из Конфигурационный файл中进行Конфигурация,включать---cluster-dnsи--cluster-domainдва параметра.

Потому что версия 1.9.0 больше не использует KUBELET_API_SERVER для связи с API в kubelet, а реализована через другую конфигурацию yaml.

nohup kubelet --kubeconfig=/mnt/app/kubernetes/conf/kubelet.yaml --hostname-override=192.68.10.37 --logtostderr=false --log-dir=/mnt/logs/k8s-kube-scheduler/ --v=2 &

Используйте это:

nohup kubelet --kubeconfig=/mnt/app/kubernetes/conf/kubelet.yaml --hostname-override=192.68.10.37 --logtostderr=false --log-dir=/mnt/logs/k8s-kubelet/ --v=2 --cgroup-driver=systemd --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice &

/mnt/app/kubernetes/conf/kubelet.yaml：

chown -R kubelet.kubelet /mnt/app/kubernetes/conf/kubelet.yaml

apiVersion: v1 kind: Config users:name: kubelet cgroupDriver: systemd clusters: name: kubernetes cluster: server: http://k8s-master:8080 contexts: context: cluster: kubernetes user: kubelet name: service-account-context current-context: service-account-contex

cgroupDriver по умолчанию — cgroupfs

• Kubelet Node Allocatable используется для резервирования ресурсов для компонентов Kube и системных процессов.,Это гарантирует, что процесс KubeиSystem будет иметь достаточные ресурсы при полной загрузке узла.
• В настоящее время поддерживаются три резервирования ресурсов: процессор, память и эфемерное хранилище.
• Node Емкость — это все аппаратные ресурсы Node, kube-reserved — это ресурс, зарезервированный для компонентов kube, system-reserved — это ресурс, зарезервированный для системного процесса, eviction-threshold — это пороговое значение вытеснения kubelet, а allocatable — это реальное планирование планировщика. Ссылочное значение пода (чтобы гарантировать, что ресурс запроса всех подов на узле не превышает выделяемый).
• Node Allocatable Resource = Node Capacity - Kube-reserved - system-reserved - eviction-threshold

--enforce-node-allocatable, по умолчанию — pods. Чтобы зарезервировать ресурсы для компонентов kube и системных процессов, вам необходимо установить его в pods, kube-reserved, system-reserve. --cgroups-per-qos,Enabling QoS and Pod level cgroups, включено по умолчанию. После включения kubelet будет управлять всеми рабочими нагрузками. Поды «cgroups». --cgroup-driver, по умолчанию — cgroupfs, другой вариант — systemd. Зависит от того, с какой контрольной группой работает контейнер. драйвер, kubelet ему соответствует. Например, если вы настраиваете Docker для использования systemd cgroup драйвер, то kubelet также необходимо настроить --cgroup-driver=systemd. --kube-reserved, используется для настройки количества ресурсов, зарезервированных для компонентов Kube (kubelet, kube-proxy, dockerd и т. д.), например --kube-reserved=cpu=1000m, Memory=8Gi, ephemeral-storage= 16Ги. --kube-reserved-cgroup, если вы установили --kube-reserved, обязательно установите соответствующую cgroup, а каталог cgroup должен быть создан заранее, иначе кубелет не будет создан автоматически и кубелет не запустится . Например, установите для него значение kube-reserved-cgroup=/kubelet.service. 。 --system-reserved, используемый для настройки количества ресурсов, зарезервированных для системного процесса, например --system-reserved=cpu=500m, Memory=4Gi, ephemeral-storage=4Gi. --system-reserved-cgroup, если вы установили --system-reserved, обязательно установите соответствующую cgroup, а каталог cgroup должен быть создан заранее, иначе кубелет не будет создан автоматически и кубелет не запустится . Например, установите для него значение system-reserved-cgroup=/system.slice. --eviction-hard, используется для настройки жесткого диска kubelet Условие вытеснения поддерживает только два несжимаемых ресурса: память и эфемерное хранилище. Планировщик не планирует новый Best-Effort при возникновении MemoryPressure QoS Поды идут к этому узлу. При возникновении DiskPressure планировщик не будет планировать новые модули на этом узле. О Кубелете Дополнительные интерпретации понятия «выселение» можно найти в соответствующих сообщениях моего блога. Kubelet Node Код Allocatable очень прост, в основном находится в pkg/kubelet/cm/node_container_manager.go. Заинтересованным студентам следует прочитать его самостоятельно. –hostname-override обозначение имя хоста, если не пусто, это значение будет использоваться в качестве идентификатора узла в кластере.

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

kubectl get cs,nodes

Если Исправлять есть порт API-сервера:

kubectl -s http://localhost:9090 get cs,nodes

Используйте управление супервизором: https://github.com/huangguisu/k8s/tree/master/supervisor/k8s-kubelet.conf

2 сервиса kube-прокси

Этот модуль реализует функции обнаружения сервисов и обратного прокси в Kubernetes. kube-proxy поддерживает перенаправление TCP и UDP-соединений, база по умолчанию — Round Клиентский трафик алгоритма Робина Воля перенаправляется на набор серверных модулей, соответствующих услуге. Что касается обнаружения сервисов, kube-proxy использует механизм наблюдения etcd для мониторинга динамических изменений в данных объекта сервиса и конечной точки в кластере и поддерживает связь между сервисом и конечной точкой, тем самым гарантируя, что изменения в IP-адресе внутреннего модуля не повлияет на посетителей. Кроме того, kube-proxy также поддерживает сеансы. affinity。

nohup kube-proxy --master http://k8s-master:8080 --hostname-override=k8s-node1 --logtostderr=false --log-dir=/mnt/logs/k8s-kube-proxy --v=2 &

kubectl -s http://localhost:9090 get nodes

Используйте управление супервизором: https://github.com/huangguisu/k8s/tree/master/supervisor/k8s-kube-proxy.conf

вопрос

1. Запустите кубелет:

См. последнюю строку: ошибка: не удалось запустить Kubelet: не удалось создать kubelet: неправильная конфигурация: драйвер cgroup kubelet: «cgroupfs» отличается от драйвера cgroup docker: «systemd»

kubeletизcgroup-driverиdocker设置из不一致导致无法запускать

Это действительно сложно. Docker использует технологию cgroup для ограничения ресурсов контейнера. dockerиззапускать Одним из параметров, конкретно среди параметров, является--cgroup-driver。

Файловый драйвер kubelet по умолчанию — cgroupfs, а файловый драйвер, используемый установленным нами докером, — systemd, что приводит к несогласованности и сбою запуска образа.

Теперь есть два пути, Один — Исправительдокер, Другой — «Исправкубелет».

Я здесь принимаю метод Исправлять докера

Уведомление:

Исправить или создать /etc/docker/daemon.json и добавить следующий контент:

{ "exec-opts": ["native.cgroupdriver=systemd"] }

или Исправлятьdocker.service

vim /lib/systemd/system/docker.service

Измените --exec-opt own.cgroupdriver=systemd на:

--exec-opt native.cgroupdriver=cgroupfs

systemctl daemon-reload

systemctl restart docker.service

kubelet отображается нормально

Исправлятьkubeletиззапускатьпараметр--cgroup-driver=systemd：

kubelet --kubeconfig=/mnt/app/kubernetes/conf/kubelet.yaml --hostname-override=192.68.10.37 --logtostderr=false --log-dir=/mnt/logs/k8s-kubelet/ --v=2 --cgroup-driver=systemd

2. Ошибка запуска kubelet:

0617 14:25:16.541259 26288 summary.go:102] Failed to get system container stats for "/system.slice/docker.service": failed to get cgroup stats for "/system.slice/docker.service": failed to get container info for "/system.slice/docker.service": unknown container "/system.slice/docker.service"

Решение, добавьте параметры запуска:

--runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice

3、 Используйте кубектл logs <podname> -n Если вы проверите логи в kube-system, то обнаружите, что такие логи существуют.

Expected to load root CA config from /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, but got err: open /var/run/secrets/kubernetes.io/serviceaccount/ca.crt: no such file or directory

Это связано с тем, что ресурс секретов, созданный Kubernetes, по умолчанию не содержит корневого сертификата, используемого для доступа к API-серверу.

Для этого требуется повторно создать сертификат и ключ.

4. Ошибка журнала:k8s-kube-scheduler

Error from server (NotFound): the server could not find the requested resource

илиkubectl get nodes

error: the server doesn't have a resource type "nodes"

Причина ошибки:

Подключенный сервер по умолчанию — http://localhost:8080.

alias kubectl=" kubectl -s http://localhost:9090"

echo alias kubectl=" kubectl -s http://localhost:9090" >> ~/.bashrc