Введение гостей: Чжао Цзыци, инженер по разработке облачных сервисов Qiniu, окончил Шанхайский университет Цзяотун со степенью магистра, присоединился к команде Qiniu Container Cloud в 2017 г. и отвечает за развертывание продукта Qiniu Container Cloud, а также создание и улучшение мониторинга журналов контейнеров. Он использует kubernetes для создания контейнеров нового поколения У него есть глубокие исследования и опыт работы с платформой управления планированием, глубокое понимание системы архитектуры kubernetes, он знаком с использованием различных инструментов развертывания и легко реализует массовое развертывание кластера и обеспечивает высокую доступность своих сервисов.
Предисловие: Появление Kubernetes делает планирование и управление контейнерными системами все проще и проще, но его собственная «сложность в развертывании» отпугивает миллионы разработчиков, поэтому продвижение этой технологии также в определенной степени ограничено. 21 октября на Architect Practice Day, совместно проводимом техническим сообществом Qiniu Cloud и K8S, Чжао Цзыци, инженер-разработчик команды Qiniu Cloud Container Cloud, объяснил, как развертывать с нуля, начиная с самой архитектуры kubernetes. рабочего кластера kubernetes, а также анализируются основные принципы работы официального инструмента развертывания kubeadm. В сочетании с трудностями, возникшими во время развертывания, поделитесь своим пониманием и решимостью. Наконец, он поделился опытом построения кластера, чтобы помочь вам быстрее и лучше достичь высокой доступности и обновления кластера одним щелчком мыши. Ниже приводится компиляция его речи.
Сегодняшняя тема — «Как более «элегантно» развернуть кластер Kubernetes». В основном я представляю вам следующие аспекты:
1. Расскажите об истории разработки решений для развертывания Kubernetes;
2. Как инструмент развертывания Kubeadm развертывает кластеры Kubernetes;
3. Проанализируйте, что Kubeadm делает за кулисами;
4. Общие проблемы, с которыми мы столкнулись при использовании Kubeadm для развертывания кластеров;
5. Используйте приемы Kubeadm.
В основном мы знакомим всех с Kubeadm, а почему мы выбираем этот инструмент, расскажем позже.
K8S - очень известная платформа планирования контейнеров. Многие люди хотят ее использовать. Новичкам все еще сложно построить полный кластер K8S. По крайней мере, нам сложно ее использовать. Это также история K8S. Оставшаяся проблема. . Возвращаясь к истории K8S, его первым решением для развертывания является файл сценария kube-up.sh, который все еще существует в его официальном репозитории.Он утверждает, что может развернуть кластер K8S одним щелчком мыши, но в процессе его использования , мы обнаружили, что есть еще много проблем. Например, процесс его инициализации очень сложный и недружественный для пользователей. Кроме того, его функции становятся очень сложными с непрерывной итерацией K8S. Самый важный момент — писать через оболочку, детям, не знакомым с оболочкой, будет очень хлопотно при развертывании, а также сложно локализовать проблему. Именно из-за этой проблемы в сообществе появилось множество самостоятельно разработанных решений для развертывания.
Рисунок 1
Именно такое количество самостоятельно разработанных решений по развертыванию включено в официальные документы K8S, которые я перехватил.Вы можете видеть текущую ситуацию его сложного развертывания. Конечно, после столь долгого периода итераций появилось несколько более зрелых решений, которые я очень всем рекомендую.Вот три наиболее известных из них:
https://github.com/coreos/tectonic-installer
https://github.com/kubernetes-incubator/kubespray (Ex Kargo)
https://github.com/apprenda/kismatic
Несмотря на то, что эти решения выдержали испытание временем, у них есть свои проблемы. Я думаю, что у них есть три проблемы: во-первых, некоторые решения для развертывания требуют длительного обучения. Во-вторых, гибкость некоторых решений для развертывания очень ограничена, и если вы хотите настроить конфигурацию для каких-то специальных мест моего кластера, они могут не достичь этого. Третье — ограниченные возможности сообщества, для поддержки новых функций скорость их разработки и зрелость их поддержки не особо впечатляют.
Здесь мы представляем такой инструмент, как Kubeadm. Рекомендуется в основном по следующим причинам:
1. Это инструмент управления развертыванием следующего поколения, официально рекомендованный K8S.Из официального позиционирования этого инструмента K8S видно, что у всего сообщества есть некоторые новые мысли о развертывании K8S. Кластер K8S не делает никаких предположений о том, как предоставляются базовые физические машины.Если он соответствует нашим требованиям, допустимы как физические машины, так и виртуальные машины. Поэтому инструменты развертывания K8S должны уделять больше внимания развертыванию компонентов K8S, а не охватывать все, включая предоставление хостов. Цель появления Kubeadm — сосредоточиться только на развертывании компонентов K8S. Поэтому чиновник также сказал, что Kubeadm — это не версия 2.0 kube-up.sh, а больше ориентирована на развертывание компонентов K8S. Именно из-за более четкого позиционирования ее развитие идет здоровее.
2. Именно потому, что его функции более понятны, использование более дружелюбно.Что касается того, насколько он дружелюбен, я представлю его вам позже.
3. Гибкость конфигурации очень высока, и она может предоставить очень богатую конфигурацию для различных требований к кластеру, будь то тестовый кластер, рабочий кластер, виртуальная машина или облачный хост. Набор решений для развертывания применим к любой из ваших сред.
4. Сообщество, стоящее за Kubeadm, очень сильное. Все мы знаем, что сообщество K8S разделено на множество групп по интересам, называемых SIG. Каждая группа по интересам имеет свою собственную тему исследования. За Kubeadm также существует группа по интересам. Инструменты поддерживаются и У них очень строгие процессы разработки и спецификации разработки, и разработчики этой заинтересованной группы являются основным персоналом K8S, поэтому они очень хорошо понимают нижний уровень, архитектуру и механизм всего K8S.Разработанные инструменты развертывания во многом надежны.
5. Kubeadm проходит официальный комплексный e2e-тест K8S, и этот инструмент будет подвергаться тщательному тестированию.
6.Право Kubeadm говорить,Kubeadm является официальной рекомендацией K8S,то есть его собственный сын.Он может запросить у K8S свои собственные требования.Сообщество K8S также обсудит, разумны ли его потребности,и также ответит на эти потребности y изменяются функции или разрабатываются новые функции. Это право на слово также является важным моментом для руководства другими общественными программами.
Именно по этим причинам в основном все сторонние известные решения сообщества признали важность Kubeadm, а также попытались использовать Kubeadm в качестве собственного базового инструмента развертывания для вторичной разработки верхних уровней. Кроме того, я лично считаю, что логика кода Kubeadm очень ясна.В процессе его использования я многое узнал о развертывании K8S и внутреннем механизме K8S через его код, который может не только улучшить наше понимание K8S, но и облегчить наши проблемы В чем проблема при позиционировании.
Рассказав о многих причинах, по которым я выбрал этот инструмент, давайте представим, как он развертывает K8S. Прежде чем представить процесс развертывания, позвольте мне кратко описать архитектуру K8S.Все мы знаем, что кластер K8S имеет две роли: главный узел и рабочий узел. Главный узел в основном отвечает за планирование и управление кластером, а рабочие — за запуск различных контейнеров. Независимо от того, какой у вас узел, если вы хотите запустить контейнер, вы должны установить компонент Kubelet.Конечно, вам нужно запустить контейнер снизу и установить компонент Docker.
фигура 2
Компоненты планирования кластера также запускаются на главном узле, в основном эти четыре (четыре синие части на рисунке выше), а именно APIServer, Etcd, Scheduler и Controller-Manager. Функция APIServer состоит в том, чтобы служить сервером всего кластера, получая запросы от двух аспектов, один из которых находится внутри кластера, включая запросы, отправленные ему этими компонентами, планировщиком и контроллером-менеджером. С другой стороны, он также получает запросы от внешних пользователей через Kubectl. Эти запросы представляют собой все добавления, удаления и изменения объектов в K8S. Наконец, информация об этих объектах хранится в etcD. Еще одним компонентом является Controller-Manager, который в основном используется для управления различными объектами в K8S. Следующий Компонент — планировщик, который отвечает за планирование пода.При создании нового пода планировщик выбирает наиболее подходящий физический узел, чтобы запланировать его в соответствии с состоянием потребления ресурсов кластера.После планирования Kubelet на этом узле будет использоваться для запуска Pod. Это компоненты, связанные с Мастером. Еще один ключевой компонент — это Kube-proxy, реализующий сервисную концепцию K8S.Сервис — это инкапсуляция подов с похожими функциями.Я хочу получить доступ к трем подам с похожими функциями, и я могу управлять их сервисами.Все. Если мы хотим добиться этого, наш Kube-прокси развернет по одному на каждом физическом узле и напишет серию правил iptables для каждого физического узла.Если Pod на этом узле хочет получить доступ к IP-адресу службы, его запрос будет изменен. по этим правилам, меняя место назначения запроса с IP сервиса на IP Pod. Другим ключевым компонентом является сетевой компонент.Чтобы реализовать сетевое взаимодействие между модулем кластера и модулем, существует множество вариантов сети, я думаю, что все это знают. Это формирует весь кластер K8S.
После знакомства с архитектурой давайте посмотрим, как инструмент Kubeadm развертывает доступный кластер K8S. Он условно делится на пять шагов:
1. Подготовьте правильно сконфигурированную машину У K8S есть только три требования к базовой машине: Во-первых, правильная операционная система, либо Ubuntu 16.04 / Debian9 / CentOS 7 / RHEL7 / Fedora 25 / HypriotOS v1.0.1. Наиболее распространенными являются Ubuntu или CentOs. Во-вторых, аппаратная конфигурация требует, чтобы у вас было как минимум 1 ГБ памяти. В-третьих, сеть требует сетевого взаимодействия между узлами в кластере. Если эти три требования соблюдены, приемлема будет ли это виртуальная машина, физическая машина или облачный хост.
2. После подготовки машины установите необходимое программное обеспечение, которое в основном устанавливается через пакет deb или пакет rpm. В основном это более важное программное обеспечение: во-первых, Docker, официальная рекомендация K8S, если кластер до версии 1.8, рекомендуется использовать Docker версии 1.12.06, если кластер K8S версии 1.8 или новее, то с помощью относительно новая версия 1.17.03. После установки Docker должен быть установлен компонент Kubelet.После установки он управляется программным обеспечением управления процессами systemd операционной системы и предназначен для самозапуска при загрузке, обеспечивая в определенной степени доступность компонента Kubelet. . Естественно, для развертывания с помощью Kubeadm установите Kubeadm на каждую машину, а также Kubectl, который мы также установим. После завершения этого шага можно гарантировать установку этих компонентов на каждом узле.
3. Запустите Мастер-узел, запустите на машине Мастер-узла такую команду, kubeadm init, эта команда поможет вам запустить компоненты, связанные с Мастером, а также четыре только что представленных APIServer, Etcd, Scheduler, Controller-Manager. , а также Кстати, будет запущен компонент Kube-proxy и Kube-DNS.Это не обязательный компонент для работающего кластера, но с этим компонентом у кластера могут быть службы DNS. После завершения этого шага стандартный вывод выведет команду с именем kubeadm join -- token xxxxxx master _ip;master _port, этот токен более критичен, это необходимая нам информация, чтобы потом безопасно добавить ноду в кластер, и он напомнит вам, что эту информацию нужно сохранить, и получить ее могут только доверенные люди. Он скажет вам, что если вы хотите добавить новую машину в кластер, просто запустите эту команду на этой машине.
4. Наш следующий шаг — запустить такую команду на рабочем узле, который формирует базовый кластер. Но этот кластер теперь является увечным кластером, потому что вы не можете работать без сетевого компонента. В это время вы смотрите на его статус, все узлы не готовы.
5. Следующим шагом будет развертывание всей сети. Это ограничение Kubeadm, ему все равно, какое сетевое решение выберет пользователь, это решение, принятое после размышлений. Сообщество считает, что выбор сетевых решений и развертывание сетевых компонентов следует оставить на усмотрение пользователя, поэтому kubeadm не будет оказывать никакой поддержки. К счастью, эти известные сетевые решения смогли работать на K8S, а работа на K8S означает, что их можно записать в виде файла yaml и развернуть в кластере. Типичное решение - calico.Официал предоставил конфигурацию, которую вообще не нужно дорабатывать, которую можно сразу разместить в кластере и в итоге сформировать полноценный кластер.
Это общий процесс развертывания Kubeadm кластера K8S. Это занимает всего пять шагов, и эти команды соответствуют тому, что он должен делать.Например, если я хочу инициализировать кластер, это kubeadm init, поэтому я говорю, что этот инструмент очень удобный инструмент.Это очень важно.
Какими характеристиками обладает развернутый кластер? 1. Кластер работает в безопасном режиме, что означает, что все коммуникации между компонентами шифруются через TLS.Любой пользователь или компонент, который хочет взаимодействовать с кластером, должен быть настроен с аутентификацией kubeconfig. 2. Все важные компоненты этого кластера, включая компоненты, относящиеся к Master, развернуты в контейнерах. 3. Кластер имеет только один главный узел. 4. Поставляется с компонентами Kube-dns.
Выше описано, как развернуть кластер через Kubeadm. Ниже приводится введение в то, что стоит за Kubeadm?
Мы видим, что Kubeadm вроде бы легко собрать весь кластер, но все же могут возникнуть некоторые проблемы во время использования.Некоторые проблемы связаны с тем, что мы находимся в Китае, а некоторые проблемы связаны с неправильной конфигурацией нашего кластера. В то время я также исследовал, что Kubeadm делает за кулисами, что дало мне много информации и очень помогло в устранении неполадок.
Есть два основных шага: первый — это инициализация kubeadm, а второй — соединение с kubeadm. Init предназначен для инициализации кластера.Во-первых, он выполнит предварительные проверки на машине, такие как компоненты, которые мы хотим запустить K8S, заняты ли его порты другими процессами, правильно ли настроены некоторые функции cgroups и так далее. Некоторые ошибки препятствуют продолжению работы Kubeadm и требуют исправления вручную для продолжения работы. После прохождения проверки будет сгенерирован токен.Токен - это токен, который будет введен новым узлом, добавленным позже.Как это делается? Как это работает? Это будет представлено позже.
изображение 3
Как реализовать безопасную среду K8S? Это то, что многие общественные программы не решают очень хорошо для всех. Режим работы K8S чем-то похож на режим CS.Вы можете видеть, что завязка на рисунке представляет собой весь APIServer, который служит сервером всего кластера для обслуживания различных клиентов, включая компоненты внутри кластера в нижнем левый угол. , такие как компоненты, такие как Kubelet и Control-manager, предоставляющие им услуги, и пользователи вне кластера, которые используют Kubectl для предоставления услуг. Если мы хотим реализовать безопасный кластер K8S, во-первых, когда клиент обращается к серверу, сервер должен быть аутентифицирован.Принятое решение представляет собой наиболее классический механизм аутентификации сервера, который требует от нашего сервера перехода к относительно известному сертификату. центр для выдачи сертификата.Если сертификат предоставляется мне, эти клиенты используют корневой сертификат этих центров сертификации, чтобы проверить сертификат сервера и узнать, является ли сервер реальным и доверенным сервером. Это решение однозначно невыполнимо с точки зрения стоимости, в компании должно быть несколько кластеров, а у меня тоже есть кластер на ноуте, купить сертификаты на каждый кластер невозможно. Kubeadm также рассматривает эту проблему. Решение, которое он принимает, — это самоподписанный центр сертификации. Он создает виртуальный центр сертификации, который доступен только внутри кластера. Этот центр сертификации выдает сертификат для APIServer и распространяет корневой сертификат через файл kubeconfig. , думать и Клиент для связи APIServer находится здесь. Если клиент хочет связаться с сервером, он проверит сертификат APIServer с сертификатом в руке.Если проверка пройдена, это означает, что APIServer является подлинным и заслуживающим доверия.Это, вероятно, процесс. После установления процесса аутентификации мы будем использовать более классический механизм симметричного шифрования для шифрования передачи данных между ними. На этом этапе необходимо установить доверие клиента к серверу.Безопасность включает в себя два аспекта: установление доверия клиента к серверу.
Рисунок 4
Клиент доверяет серверу, а сервер доверяет клиенту. Для этого требуется, чтобы файл Kubeconfig был выдан всем компонентам, которые хотят взаимодействовать с APIServer. Это включает аутентификацию K8S и механизм аутентификации. Я не знаю, все ли хорошо понимают этот механизм. Вам нужно действительно построить кластер, который могут быть использованы в производстве.Это часть того, что вы должны учитывать. Механизм аутентификации K8S разделен на три шага, которые можно увидеть на рисунке выше. Эти три шага перечислены. Когда какой-либо клиент хочет отправить запрос на APIServer, он должен перед этим пройти тройную проверку. : аутентификация, аутентификация и контроль доступа. Я суммирую то, что делают эти три проверки, в одном предложении, что равносильно тому, что клиент отвечает на эти три вопроса, если он хочет отправить запрос. Есть ли у вас право делать то, что вы хотите сделать в запросе, имеете ли вы право делать то, что вы хотите сделать? В-третьих, вы должны установить некоторые параметры для того, что вы хотите запросить. ? На четвертом шаге Kubeadm выдает kubeconfig каждому клиенту, чтобы клиент мог ответить на вопрос, кто вы такой. Этот шаг очень похож на механизм предыдущего шага.На предыдущем шаге мы построили виртуальный центр сертификации, который не только выдал серверный сертификат для APIServer, но и выдал каждому клиенту клиентский сертификат.Этот сертификат позволяет APIServer аутентифицировать, кто вы есть.Это устанавливает доверие между сервером и клиентом. Этот клиент, который должен выдать сертификат, включает в себя Kubelet, Controller-Manager, Scheduler, и мы будем использовать Kubectl для создания кластера позже, а также мы создадим файл kubeconfig для администратора.
Запустите компоненты, связанные с Мастером, такие как Etcd, APIServer, Controller-Manager и Scheduler, как показано на рисунке. Его метод запуска основан на методе статического модуля. Этот метод заключается в записи yaml-файлов этих компонентов в каталог /etc/kubernetes/manifests. Kubelet будет периодически опрашивать файлы в этом каталоге. Если в этом каталоге создается новый файл файл каталога, запустите модуль на этом узле в соответствии с требованиями файла. Компоненты, относящиеся к Мастеру, запускаются через статические модули. После запуска этого файла Kubeadm продолжит опрос API. Интерфейс работоспособности сервера не будет считать, что важные компоненты кластера запущены, пока интерфейс работоспособности не вернет 200. Это место, где у нас часто возникают проблемы во время использования, когда все бегут в это место, они застревают и ждут. Мы подробно обсудим, какие проблемы часто возникают в этой сфере.
Рисунок 5
Если предыдущий шаг пройден, мы выполним последующую работу по инициализации в кластере, в том числе добавим некоторые метки и пометки к главному узлу, чтобы гарантировать, что модули, связанные с главным, будут развернуты на этом узле.
Создайте два компонента: Kube-proxy и Kube-dns.
Чтобы добавить новые узлы позже и более безопасным способом. Kubeadm надеется установить двустороннее доверие. Как показано на рисунке, левая сторона представляет существующий кластер, а правая сторона представляет вновь добавленный узел. Установление двустороннего доверия означает, что существующий кластер должен доверять вновь добавленному узел., является достоверным и верным. Кроме того, вновь добавленные узлы также должны верить, что кластер, к которому они присоединяются, является доверенным. токен, потому что это основа для построения двустороннего доверия. Поскольку это очень связано с командой Kube adm join позже, я познакомлю вас с ней.
Установите доверие в первом направлении, то есть как новый добавленный узел считает, что кластер, к которому он присоединяется, является доверенным кластером? Созданием этого направления является общедоступная информация Cluster-info, установленная Kubeadm.Cluster-info на самом деле является объектом configmap, который в основном хранит три части информации. Первая информация — это корневой сертификат виртуального центра сертификации, а вторая — это информация, относящаяся к кластеру, например адрес APIServer. Третья часть информации требует, чтобы мы объединили эти две части информации, хэшировали эту информацию с помощью токена, известного только тем, кому мы доверяем, и объединили эти три вместе, чтобы сформировать Cluster-info, которая является полностью внешней Exposed, что означает, что любой может получить эту вещь, не предоставляя никакой аутентификационной информации. Соответственно, Кубадм Команда соединения сначала получает информацию о кластере. Только люди, которым мы доверяем, знают токен. Она может использовать токен, чтобы проверить, заслуживает ли доверия информация о кластере, чтобы построить доверие от недавно добавленного узла к направлению кластера.
Во-вторых, как мне заставить кластер поверить в то, что добавляемые мной узлы настоящие? Он также основан на только что упомянутом механизме токенов. Это реализуется путем сохранения токена в кластере одним способом и включения механизма аутентификации. Конечный эффект заключается в том, что любой клиент отправляет запрос к APIServer. Если заголовок запроса содержит информацию о токене, он будет аутентифицирован APIServer как действительный. , что фактически создает доверие к кластеру для работника. После успешного установления двустороннего доверия главный узел выдает доступный файл kubeconfig вновь добавленному узлу, и вновь добавленный узел может использовать этот файл для добавления себя в кластер.
Проблемы, возникающие при использовании инструмента Kubeadm
1. С проблемой невозможности сброса инсталляционного пакета могут столкнуться отдельные пользователи. Инструменты Kubeadm, Kubelet и Kubectl, которые мы только что представили, устанавливаются через пакеты deb и rpm, но официальный веб-сайт предоставляет для установки только источники установки Google, которые не могут быть установлены в нашей стране. Я рекомендую зеркальный источник Китайского университета науки и технологии.Этот источник предоставляет источник установки, синхронизированный с официальным источником Google, поэтому вы можете испытать в нем последнюю версию K8S.
2. С проблемой невозможности загрузки исходника образа Docker сталкиваются и наши отечественные пользователи. В процессе инициализации кластера Kubeadm будет загружено много образов.Если вы не настроите его, он будет загружаться из официального источника изображений Google, что недоступно нашим домашним пользователям. Итак, нам нужно сделать две вещи: во-первых, найти источник, который синхронизирует внутренние и официальные источники Здесь мы рекомендуем источник Alibaba Cloud. Во-вторых, указать Kubeadm для загрузки из этого источника. Установив для переменной среды KUBE_REPO_PREFIX значение Kubeadm, вы можете заставить его загружать все изображения из этого источника. Но есть одно исключение — изображение паузы: когда K8S запускает модуль, он запускает не только указанное пользователем изображение, но и изображение паузы. Инициализируйте образ для пользователя, а его адрес загрузки по умолчанию — официальный адрес Google. И этот адрес не повлияет на него, даже если переменные окружения Kubeadm настроены, поэтому скачайте его здесь. Поскольку на самом деле это параметр Kubelet, нам нужно изменить параметры Kubelet, чтобы его можно было загрузить с домашнего зеркала. Если вы хотите испытать это в Китае, вы должны обратить на это внимание. Эта точка не будет изменена успешно, что приведет к сбою запуска кластера.
3. Проблема определяется параметром APIServer --advertise-address, этот параметр используется для указания адреса связи между APIServer и другими компонентами или его адреса прослушивания. Его метод определения по умолчанию будет выбирать IP-адрес сетевой карты машины по умолчанию, что иногда неуместно, потому что у нас будет такой сценарий в нашем собственном использовании.Некоторые из наших машин могут по умолчанию использовать общедоступную сетевую карту.Мы надеемся, что внутренняя Компоненты кластера Вещи, которые взаимодействуют друг с другом, проходят через трафик интрасети, поэтому в настоящее время мы все еще используем этот метод оценки по умолчанию, который позволит APIServer привязать общедоступную сетевую карту. Если ваша среда настроена таким образом, рекомендуется выполнить привязку к внутренней сетевой карте таким образом. В Kubelet также есть такой параметр, который называется --node-ip. , в таком случае он будет привязан к общедоступной сетевой карте по умолчанию.Если ваша среда похожа на эту, рекомендуется настроить адрес интрасети в командной строке. Обнаружение этой проблемы связано с нашим собственным реальным сценарием использования.Когда мы хотим развернуть кластер с помощью программного обеспечения для управления виртуальными машинами Vagrant, возникнут некоторые проблемы, поскольку оно создает сетевую карту nat для каждой виртуальной машины в качестве сетевой карты по умолчанию. , его IP-адрес Фиксированный, если вы создаете две виртуальные машины, сетевая карта по умолчанию для обеих виртуальных машин имеет один и тот же адрес. Если в это время он все еще указан таким образом, политика по умолчанию приведет к тому, что все адреса pod будут одним и тем же адресом сетевой карты NAT. Официальный представитель K8S также дает план, если вы используете требования этого кластера развертывания, вам следует обратить внимание на эту проблему.
4. IP-адрес службы DNS и параметры Kubelet --cluster-dns не совпадают. Kubeadm по умолчанию создает две службы.Одна служба используется для предоставления службы APIServer, а другая служба используется для предоставления службы DNS Kube.Эти два адреса службы не генерируются случайным образом, но имеют определенные правила. Kubeadm сначала укажет диапазон служебных ip, значение по умолчанию 10.96 .0.0/16, в соответствии с этим диапазоном можно сгенерировать два адреса по определенным правилам. Адрес службы APIServer будет принимать первый адрес этого сегмента сети, то есть 10.96.0.1, Kube. DNS более жесткий, он будет добавлять 1 перед последним 0 в качестве IP-адреса службы, то есть 10.96.0.10, и метод настройки не может быть изменен. Так что это правило по умолчанию. У Kubelet также есть параметр с именем --cluster-dns.Каждый раз, когда Kubelet запускает модуль, он использует этот параметр в качестве сервера имен контейнера. То есть, если контейнер хочет разрешить доменное имя, каков сервер имен его службы DNS. Если вы хотите использовать службу DNS в кластере, вы должны указать IP-адрес сервера Kube DNS.По умолчанию он настроен на 10.96.0.10.Если вы используете конфигурацию по умолчанию, вы не найдете никаких проблем, и кластер работает хорошо. Но однажды в производственной среде, такой как ваша, сервис необходимо заменить диапазон ip, он сгенерирует новый IP-адрес Kube-DNS. Если он не будет синхронизирован вовремя, запускаемый вами модуль не сможет использовать эту службу DNS. Это проблема, с которой мы столкнулись в то время, и мы надеемся, что вы избежите ее в будущем.
Наконец, познакомим с навыками использования Kubeadm:
Изображение 6
У Kubeadm есть параметр — параметр config, мы можем передать ему yaml-файл, yaml-файл описывает объект в K8S, который называется MasterConfiguration. На приведенном выше рисунке я просто отрезал часть информации описания этого типа объекта.Он предоставляет очень богатые настраиваемые элементы конфигурации для кластера.Вы можете настроить конфигурацию для этого кластера и положение этого кластера.Например, если вы хотите установить версию K8S, диапазон служебных IP-адресов и т. д. Если вы используете этот инструмент, используйте такие файлы гибко. Два распространенных варианта использования описаны ниже.
1. Иногда пользователи хотят испытать новые функции K8S.Как правило, новые функции требуют изменения параметров командной строки запуска основных компонентов, таких как APIServer, но основные компоненты, запущенные с помощью Kubeadm, могут не добавляться по умолчанию.Если я хочу использовать его, я могу найти параметр piServerExtraArgs в MasterConfiguration, и я могу прописать в нем дополнительные параметры APIServer, чтобы запущенный кластер заносил в него эти параметры. Точно так же Controller-manager и Scheduler также предоставляют нужные вам параметры.
2. При нормальных обстоятельствах наши кластеры являются кластерами интрасети и предоставляют только один IP-адрес общедоступной сети. Я надеюсь получить доступ к этому кластеру через локальную сеть. В настоящее время к нему можно получить доступ только через IP-адрес общедоступной сети. Как это должно быть настроено в это время? Мы думаем шаг за шагом, как мы только что сказали, когда Kubeadm инициализируется, он сгенерирует файл Kubeconfig для администратора и загрузит его. Оказывается, это невозможно, потому что этот кластер является интранет-кластером, а адрес APIServer в файле Kubeconfig — это интранет-ip. Так что доступ к нему невозможен. Затем я могу изменить IP-адрес внутренней сети на IP-адрес общедоступной сети APIServer? После экспериментов выяснится, что это невозможно, и сообщу Произошла ошибка, что не удалось пройти аутентификацию. Почему не проходит сертификация? Это необходимо для проверки процесса аутентификации сервера, о котором мы только что говорили.Я только что сказал, что когда клиент хочет получить доступ к APIServer, ему нужно получить сертификат сервера, проанализировать его, посмотреть, какие псевдонимы есть у APIServer, а затем использовать клиент для получить доступ к APIServer. Сравните IP-адрес или доменное имя с псевдонимом, чтобы увидеть, охватывает ли он уже псевдоним. Если он закрыт, я считаю этот сервер аутентифицированным. Поскольку сертификат APIServer, созданный кластером Kubeadm, который мы развернули в этом сценарии, не будет записывать IP-адрес общедоступной сети в сертификат, доступ с IP-адресом общедоступной сети не пройдет проверку. Решение очень простое, просто подпишите общедоступный сетевой IP-адрес в сертификат, поэтому этот файл yaml также предоставляет нам такую опцию, называемую apiServerCertSANs, до тех пор, пока вы пишете общедоступный сетевой IP-адрес здесь, а затем запускаете кластер, это сертификат может иметь этот IP-адрес общедоступной сети, я могу использовать только что упомянутый процесс, загрузить файл и изменить адрес APIServer на IP-адрес общедоступной сети, а затем я могу получить к нему доступ. Это очень распространенное требование в моей работе, которое сделает вашу разработку более удобной.
3. Далее рассмотрим общее требование.Упомянутый только что Master-компонент создается в виде статического пода.Если кластер сейчас запущен, то я не могу переразвернуть кластер. Я также хочу добавить параметр командной строки в главный компонент, например APIServer, что мне делать? Обновлять можно только динамически. Мы перепробовали множество методов и обнаружили, что успешно обновить можно только такой процесс: сначала переместите yaml-файл APIServer из каталога /etc/kubernetes/manifests, а затем измените его и переместите обратно, чтобы добиться обновления. Мы исследовали официальное заявление K8S, которое связано с логикой кода Kubelet, но официальный представитель K8S считает, что статические Pod — это форма, которая не будет существовать долго, и в будущем эта функция будет использоваться все реже и реже, поэтому код не будет модифицирован для этой проблемы. Если вы все еще используете статический модуль для управления своими контейнерами, вы можете использовать только это решение, его невозможно решить.
Вышеизложенное – это знания, которыми я делюсь с вами сегодня. Qiniu Cloud Container Cloud вот-вот появится в сети. Мы представим некоторых тестовых пользователей во время онлайн-процесса. Чтобы подать заявку, чтобы стать тестовыми пользователями, вы можете отсканировать QR-код ниже, чтобы заполнить анкету.
Внутреннее бета-приложение Qiniu Container Cloud
Вопрос: Если в K8S две личности, Master и Worker, что будет, если Master повесит трубку?
Чжао Цзыци: Высокая доступность всегда была важной заботой сообщества.Решение высокой доступности нашего собственного кластера также реализуется в максимально возможной степени, следуя самым передовым решениям сообщества. Текущим статусом высокой доступности в сообществе можно поделиться.Упомянутые основные компоненты управляются статическими модулями, которые очень негибкие. Решение, принятое сообществом, состоит в том, чтобы управлять компонентом APIServer через DaemonSet и запускать три APIServer. Эти три APIServer могут предоставлять внешние сервисы одновременно, а два других Master-компонента Controller-Manager и Scheduler запускаются через Deployment, а также запускаются три. ETCD также обеспечивает доступность за счет кластеризации. Посредством этих операций можно добиться того, что Мастер один повесит трубку, а два других окажут услуги.
Вопрос: Мастер-контейнер необходимо загрузить со склада Google, нужно ли предоставлять дополнительные параметры для загрузки контейнера, каждой сети Kubelet нужен контейнер, предоставляемый подом, этот контейнер можно установить перед загрузкой, вы говорите об изменении параметров на узел, его можно настроить перед установкой, без необходимости устанавливать его на каждый готовый узел?
Чжао Цзыци: Я только что упомянул, как изменить контейнер загрузки Kubelet. Версия K8S, которую мы используем сейчас, относительно старая, с двумя версиями, 1.6 и 1.7. В более поздних версиях эта функция будет интегрирована, что будет более удобно, и есть нет необходимости вручную настраивать Kubelet. Заставит Kubeadm сгенерировать рабочие параметры параметра Kubelet и применить этот параметр ко всем Kubelet в кластере.
Вопрос: О статических подах я говорил в конце. Предыдущая версия статических подов относительно старая. При изменении yaml файла можно напрямую обновить под внутри. С новой версией тоже сталкиваемся с этой проблемой. не вступит в силу немедленно. Мы также должны выяснить, есть ли у официального параметры, чтобы он вступил в силу напрямую. Ваш метод - удалить файл, изменить его снаружи, а затем переместить. Наш метод - перезапустить Kubelete услугу напрямую, что также может привести к ее немедленному вступлению в силу.
Чжао Цзыци: Это ваш опыт.Как мы только что сказали, мы также прочитали официальное заявление K8S.Они не рекомендуют всем использовать эту форму, поэтому они не будут вносить изменения в это решение или решать его. Они больше не думают об этом.