Поскольку контейнеры становятся все более и более популярными, k8s также стал стандартом для многих компаний.Kubernetes предоставляет набор простых в использовании API-интерфейсов для текущей основной инфраструктуры. Используя преимущества Kubernetes, мы можем добиться более высокого и более общего управления автоматизацией инфраструктуры. Исходя из этого, CoreOS реализует набор «автономного вождения» Kubernetes. В этом докладе от CoreOS Дэн ХунчаоТехнические детали будут объяснены на основе опыта собственного участия. И возьмем оператор etcd, который в основном отвечает, в качестве примера, чтобы объяснить общий способ построения оператора в Kubernetes.
Дэн Хунчао: Для меня большая честь быть здесь сегодня. Давайте сначала познакомимся с оператором, который используется для автоматизации работы и обслуживания приложений. Приложение здесь относится к вашему коду + конфигурации, программе, логическому уровню и уровню развертывания.
один пример
Перед тем, как мы начнем, давайте расскажем историю.У этой истории вообще много кругов друзей.Начали мы с круга друзей.Всем известно,что pingCAP не только хорошо работает в базе данных,но и хорошо работает в окружающем пространстве .
фигура 1
Чтобы продавать периферийные устройства, мы должны создать веб-сайт.Тогда Huang Dongxu является большой коровой GO.Язык GO позволяет нам создать веб-сайт очень быстро. Golang позволяет нам сделать сайт очень быстро. Так что вскоре у нас был прототип, и пусть все оценят дизайн лежащих в его основе программистов.
фигура 2
Можно сказать, что GO — очень хороший язык, он позволяет очень просто и удобно реализовать переход от идеи к программе. Затем мы пишем программы на локальном уровне, и их нужно развернуть на уровне сервера. Сначала нам нужно упаковать эту программу и опубликовать наш сервисный пакет. Для этого требуется настроить хранилище и другие ресурсы в кластере серверов, развернуть программу и запустить ее для обслуживания этих пользовательских запросов.
Развертывание приложений без сохранения состояния
Далее я расскажу вам, как упаковать эту программу. Как показано на рисунке 4, в первую очередь это упакованная команда, представляющая собой образ контейнера. Мы опубликуем эту запись, и когда мы ее опубликуем, у нас уже будет работающий кластер. Теперь запустим приложение. Во-первых, мы не можем получить доступ к этому локальному шлюзу, мы будем использовать порт 30080 локально, а это значит, что мы нашли другой способ найти этот сервис. Мы видим, что сервис в это время развернут и мы можем получить к нему доступ.
изображение 3
С контейнерной технологией нам очень удобно — даже если я никогда не пишу приложения, я могу очень легко развернуть приложение. И мы просто использовали два инструмента контейнера в этом процессе,
Рисунок 4
Это соответствует двум этапам разработки контейнера. На первом этапе мы стандартизируем способ упаковки приложений. Таким образом, формат вашего пакета услуг при передаче по сети одинаков, если вы используете этот стандартный формат для упаковки вашего Независимо от того, на какой платформе оно работает, независимо от того, кто является поставщиком услуг — Google, Tencent Cloud или Alibaba Cloud, — ваш пакет услуг можно запускать где угодно и он совместим. Тогда как раз сейчас этот процесс локален, это индивидуальный уровень. При развертывании нам необходимо выполнить развертывание в кластере серверов, что часто требует от нас настройки, управления и планирования ресурсов этого кластера. Итак, на втором этапе нам понадобятся некоторые инструменты для управления этим кластером.
Рисунок 5
приложение с отслеживанием состояния
Можно сказать, что с развитием технологии контейнеров очень просто развернуть внешнее приложение этого типа без сохранения состояния. И, насколько я знаю, большинство
Большинство этих корпоративных приложений являются приложениями без сохранения состояния, включая сам Google. Это также является отправной точкой контейнерной технологии. Однако по-прежнему очень сложно развернуть некоторые приложения с отслеживанием состояния, и на данном этапе ни у кого нет хорошего решения. Так что же такое приложение с отслеживанием состояния? Я приведу здесь несколько примеров.
Например, базы данных, какое-то промежуточное ПО, такое как Kafka, heron и spark для больших данных и т. д. Это все госсервисы. Можно сказать, что развертывание этих сервисов с отслеживанием состояния очень сложно, намного сложнее, чем эти фасадные приложения без сохранения состояния. С одной стороны, требуемые ими конфигурации более сложные, и их сейчас много.Во-первых, во многих компаниях будут специальные команды для их управления, они не будут управлять таким простым управлением, а будут иметь специальные команды для управления каждым кластером. Многие компании даже зарабатывают деньги, помогая управлять этими кластерами приложений с отслеживанием состояния.
prometheus
Сначала пройдемся по нескольким примерам, прежде всего прометей, который является инструментом с открытым исходным кодом.Когда мы запускаем этот прометей, с одной стороны, ему нужно знать порты выбранных сервисов, он будет сканировать эти порты и захватывать свою матрицу и, наконец, интегрировать матрицу в интерфейс. С другой стороны, он должен схватить эти правила, а затем по этой Матрице и правилам, поэтому вы столкнетесь с некоторыми очень сложными реляционными зависимостями, когда будете в летнем прометее. При развертывании вам нужно не только знать правила развертывания самого prometheus, но, с другой стороны, вам также необходимо выполнять некоторые повторяющиеся операции по эксплуатации и обслуживанию, основанные на различных фундаментальных средах.
Изображение 6
Etcd
Etcd — надежный и стабильный репозиторий для обнаружения сервисов с высокой доступностью. Из-за архитектуры он будет давать информацию всем участникам при запуске, чтобы все проголосовали за создание лидера, а затем нам нужно настроить эти идентификаторы, настроить эту операцию, настроить этот порт, а затем мы должны настроить каждый из них. Делайте одно и то же снова и снова, они просто статичны. Если он динамический, нам также нужно выполнить некоторые последовательные операции.
Рисунок 7
Self-updating Kubernetes
Всем известно, что ОС обновляется автоматически, потому что у нее есть набор серверов автоматического обновления. Затем в другом своем продукте он использует этот набор серверов обновлений для предоставления услуг автоматического обновления. Когда выйдет обновление, его политика будет выглядеть как на рисунке 8, и он скажет, что мне нужно обновить APIServer до 1.6, а etcd — до 3.1.4. Когда мы хотим обновить etcd, при обновлении мы сначала делаем резервную копию данных кластера, а затем нам также нужно проверить эти пути обновления. Например, если я перейду с 3.0 на 3.2, он сначала перейдет с 3.0 на 3.1, а затем с 3.1 на 3.2. Затем кластер выполняет непрерывное обновление. Убедитесь, что каждый из них успешно обновлен. Наконец, когда весь апгрейд будет неудачным, он сделает откат.
Рисунок 8
Исходя из нескольких рассмотренных нами примеров, почему развертывание этих приложений с отслеживанием состояния, а также их развертывание и управление ими сложнее, чем приложений без сохранения состояния? Это потому, что в них есть эти сложные операции и логика. Это требует от вас настройки таких операций, как идентификаторы, сетевые ресурсы, хранилище и т. д. И они выполняют некоторую повторяющуюся работу в зависимости от окружающей среды.
operator
Таким образом, именно для решения этой проблемы введена концепция, называемая оператором.Из программного обеспечения мы будем моделировать работу и обслуживающий персонал, чтобы постоянно обновлять и выполнять некоторую настройку, чтобы обеспечить нормальную работу вашего кластера и вашего сервиса. Далее принцип работы оператора показан на рисунке 9.
Рисунок 9
В основном он состоит из трех шагов.Во-первых, он будет наблюдать за текущим состоянием, таким как текущее количество узлов кластера — три, текущая версия кластера и т. д., и сравнивать то, что отличается от ожидаемого. Например, он обнаружил, что мое ожидаемое количество узлов кластера должно быть 5, а моя ожидаемая версия должна быть 1.3.0. В конце концов, он будет действовать, чтобы исправить это. Может быть, он найдет способ добавить этих членов, превратив их с трех в пять, может быть, он обновит эти члены один за другим, обновив их с 1.2.3 до 3 . После завершения раунда он возвращается в исходную точку для повторного наблюдения и повторения такой работы, точно так же, как операционный и обслуживающий персонал, работающий 24 часа в сутки, чтобы обеспечить нормальную и здоровую работу кластера или службы.
Поэтому, основываясь на этой идее, мы написали оператор etcd для управления и развертывания кластеров ectd. Рисунок 10.
Рисунок 10
Во-первых, оператор ectd может помочь вам в повседневной эксплуатации и обслуживании.Например, в этом расширении вам нужно расширить с трех узлов до пяти или уменьшить с пяти узлов до трех узлов. Затем создайте резервную копию, потому что etcd все-таки хранит данные, поэтому нам нужно автоматически создать резервную копию этого кластера. Существует также отработка отказа.Если у вас умирает член, оператор etcd автоматически заменяет его новым членом, чтобы обеспечить нормальную работу кластера. А для более продвинутых пользователей мы даже предлагаем более продвинутые функции, такие как восстановление, TLS и многое другое.
Если оператор etcd реализует вышеуказанную функцию, можно сказать, что это RDS, но лично я считаю, что оператор etcd гораздо более продвинут, чем RDS. Потому что этот оператор etcd имеет набор декларативных API, как показано на рисунке 11. Что такое декларативный API, где ты просто должен сказать мне, что я хочу получить в итоге? Мне не нужно точно говорить, как это сделать шаг за шагом.
Рисунок 11
Приведу пример: например, если я хочу создать кластер etcd, я говорю количество узлов, что оно равно 3, а затем версия кластера 3.1.5, я делаю резервную копию каждые 300 секунд, т. е. , каждые 5 минут Мое максимальное количество резервных копий равно 5, поэтому мы даже можем настроить его, чтобы сказать, нужно ли мне хранить его в этом PV или в S3 и т. д. Это декларативный API. То есть декларативный API может сделать строки внутри совместимыми и интероперабельными. Например, API, который мы только что установили, является более структурированным. Но мы также можем преобразовать его для связи с другими линиями. Его также можно преобразовать в API GO.
Рисунок 12
Рисунок 13
Суммировать
Мы прошли два этапа разработки контейнеров: первый — стандартизация формата, второй — упростить для контейнеров настройку этих ресурсов, управление и планирование этих ресурсов. Затем постепенно, с диверсификацией этого приложения и слов, специфичных для приложения, в будущем будет все больше и больше автоматизации для специализированных приложений в контейнерах. Это также причина, по которой мы подталкиваем оператора.На рисунке 14 показано направление развития оператора в будущем, который будет применять некоторую автоматизацию, ориентированную на обслуживание.
Рисунок 14
Наконец, давайте определим, что такое оператор и что prometheus будет делать в будущем. Ядром оператора является автоматизация.Мы также видим, что API оператора является декларативным, а затем API оператора также является облачным, и оператор также настраиваемый.Вы можете настроить prometheus для работы в разных средах.
Рисунок 15
Наконец всем спасибо!