почему AKS, EKS, GKE лучше, чем k8s. Можно ли сказать, что архитектура k8s является основой этих 3. Как они усиливают друг друга?

AKS, EKS и GKE — это так называемые управляемые решения kubernetes. Их цель и функциональность в основном одинаковы. Конечно, есть некоторые различия, особенно в том, как такой управляемый кластер kubernetes может быть интегрирован с остальной частью конкретной облачной платформы, но все поставщики делают все возможное, чтобы он ни в чем не уступал конкурентам.

Почему AKS, EKS, GKE лучше, чем k8s. Можем ли мы сказать, что архитектура k8s является базовой? из них 3. Как они взаимодействуют друг с другом?

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

Да, эти 3 решения полностью основаны на kubernetes с открытым исходным кодом с некоторыми дополнительными модификациями и улучшениями, разработанными отдельно каждым облачным провайдером. Подробнее об истории kubernetes можно прочитать в этой статье Википедии. Короче говоря, он был первоначально разработан Google на основе их опыта работы с их внутренней системой для оркестровки контейнеров под названием Borg и впоследствии выпущен как технология с открытым исходным кодом:

Kubernetes v1. 0 был выпущен 21 июля, 2015. [13] Наряду с выпуском Kubernetes v1.0 Google сотрудничал с Linux Foundation для создания Cloud Native Computing Фундамент (CNCF) [14] и предложила Kubernetes в качестве исходной технологии.

Чтобы настроить свой кластер kubernetes самостоятельно, у вас есть такие инструменты, как kubeadm, которые упрощают весь процесс, но при этом дают вам полный контроль над вашей средой kubernetes. Но у него есть как преимущества, так и недостатки. С одной стороны, вы имеете полный контроль над своим главным узлом, а с другой — вы несете полную ответственность за администрирование такой среды, и если что-то пойдет не так, например. с вашим производственным кластером вы тот, кто должен это исправить.

Некоторым пользователям требуется еще более детальный контроль как над процессом настройки кластера, так и над его администрированием. Вы, наверное, слышали о подходе к настройке кластера kubernetes на 100% вручную. Это называется тяжелый путь kubernetes. Если вы проходили через это хотя бы раз, то наверняка знаете, насколько это сложный и утомительный процесс.

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

Преимущества такого решения? Ну, без сомнения, их много. Меньше усилий по администрированию, меньше энергии и времени, которое вам нужно посвятить настройке и управлению самим кластером kubernetes, и вы можете сосредоточиться в основном на развертывании рабочей нагрузки и управлении ею. Однако каждое преимущество связано с некоторыми компромиссами, и здесь, выбрав одно из управляемых решений Kubernetes, вы отказываетесь от полного контроля над своей средой.Имейте в виду, что GKE, AKS и AKS не дают вам доступа к главному узлу. Поэтому, если вы хотите перенастроить свой kube-apiserver или другой элемент кластера, запустив его с каким-то совершенно другим флагом, вам не разрешено это делать. Взамен вам все равно, выйдет ли из строя весь главный узел, поскольку ваш облачный провайдер несет ответственность за правильное управление им для вас.

Итак, как я уже сказал, это полностью зависит от ваших конкретных потребностей и ожиданий. Вы можете спросить так же: «Зачем использовать облако, IaaS, PaaS, SaaS, если мы можем управлять нашей инфраструктурой самостоятельно? Есть так много дата-центров, которые позволяют разместить свои физические серверы, так зачем заморачиваться с некоторыми облачными решениями?» — Но вы, наверное, согласитесь, что использование облака имеет много преимуществ. Он обеспечивает беспрецедентный уровень масштабируемости, эластичности и высокой доступности, и это лишь некоторые из них, но вы, вероятно, знаете, что этот список очень длинный.

Можем ли мы в облаке организовать оркестровку контейнеров без вышеуказанного? services означает, что мы можем иметь вычислительные экземпляры, такие как ec2/VM, и устанавливать k8s (проект с открытым исходным кодом) на этих узлах, что означает создание собственных k8s кластер?

Конечно, можно. Вы можете настроить свою собственную среду kubernetes с полным доступом к главному узлу на виртуальных машинах GCP Compute Engine, но, как я уже сказал, это требует дополнительных усилий по администрированию. Вы можете настроить свой кластер kubernetes на виртуальных машинах в облаке так же, как вы делаете это локально.

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

Ну, вы всегда можете разработать собственное решение для автоматизации этого процесса, но в целом, если вы настраиваете свой кластер kubernetes вручную, ответ таков: вы не можете. Это также большое преимущество управляемых решений kubernetes, поскольку kubernetes с открытым исходным кодом просто не имеет таких функций и не будет автоматически создавать дополнительный узел, когда один из них выходит из строя. На самом деле он даже не предназначен для таких целей и работает на другом уровне. Речь идет об управлении контейнерами, на которых выполняется наша рабочая нагрузка, а не об управлении облачной инфраструктурой.

Взгляните на эту статью, в которой представлен общий обзор Google Kubernetes Engine, включая преимущества GKE по сравнению с kubernetes с открытым исходным кодом:

Kubernetes в Google Cloud

Когда вы запускаете кластер GKE, вы также получаете преимущества передовых функции управления кластером, которые предоставляет Google Cloud. К ним относятся:

• Google Cloud балансировка нагрузки для экземпляров Compute Engine
• Пулы узлов назначать подмножества узлов внутри кластера для дополнительных гибкость
• Автоматическое масштабирование количества экземпляров узла вашего кластера
• Автоматические обновления для программного обеспечения узла вашего кластера
• Автоматическое восстановление узла для поддержания работоспособности и доступности узла
• Ведение журнала и мониторинг с пакетом операций Google Cloud для обеспечения видимости вашего кластера

Что касается:

Если нет, то почему люди сравнивают k8s, EKS, aks и gke, поскольку k8s не должен быть частью этого?

Для сравнения EKS с AKS с GKE есть простая причина.За каждым из них стоит другой крупный игрок, и это просто конкурентоспособные решения, пытающиеся быть на шаг впереди конкурентов, что в принципе тоже очень положительно, так как дополнительно стимулирует их интенсивное развитие.

Сравнение каждого из них по отдельности с k8s с открытым исходным кодом также имеет смысл, так как для некоторых целей может быть лучше рассмотреть возможность создания собственного кластера k8s с нуля и иметь очень детальный контроль над каждой деталью, например установка определенных флагов kube-apiserver или kube-scheduler запускается с и т. д.

В нескольких местах, которые я нашел, люди говорили, что это похоже на обычный Hadoop и Cloudera Hadoop (полностью управляет кластером Hadoop, что упрощает жизнь и добавляет значение в таблице).

да, это очень точное сравнение. Имейте в виду, что настройка сложного кластера, состоящего из множества элементов, намного сложнее, чем установка простого http или сервера баз данных (но вы также можете найти хостинг-провайдеров, которые украсят вашу жизнь проще и предлагают полностью управляемые решения). Даже если они состоят из нескольких реплик, обычно их настройка требует меньше времени и сил, чем настройка кластера, состоящего из множества взаимосвязанных элементов, где один сильно зависит от другого. Если вы внимательно посмотрите на эти элементы в kubernetes, вы обнаружите, что это не такая однородная среда, и хотя, когда вы настраиваете все автоматически, это может показаться таковым, в на самом деле это не так.

Я надеюсь, что это пролило свет на ваше понимание kubernetes и, в частности, смысла использования управляемых решений kubernetes.