Я был на KubeCon 2017 в Остине, штат Техас (Go Bruins!). Этот пост - краткое изложение моего опыта. Если вас интересует что-то не освещенное, просто спросите 🤓

Кубикон был огромным

Тот факт, что конференция была распродана с более чем 4200 участниками, продолжала выходить из спикеров и в разговорах в коридоре. Последний KubeCon в Европе собрал около 1000 человек. В этом году посещаемость была больше, чем за все предыдущие KubeCons, вместе взятые. Все были потрясены ростом посещаемости.

Несмотря на то, что это впечатляет, оно отражает распространение самого Kubernetes, поэтому не должно быть слишком шокирующим. Не удивлюсь, если посещаемость KubeCon 2018 в Северной Америке увеличится вдвое.

Тенденции: сервисные брокеры

Я вел постоянный подсчет того, как часто Open Service Broker API упоминался в разговорах. Это было много! Казалось, что представители Google, Microsoft и IBM должны были упомянуть об этом. Компонент каталога сервисов Kubernetes - это то, как они планируют перепродать вам свои облачные предложения, так что я думаю, это имеет смысл.

Многие выступавшие, упоминающие API OSB (Open Service Broker), неправильно понимали, как он реализуется. В разговорах и рецензиях вы увидите упоминания о том, как это помогает избежать привязки к поставщику. Поле выглядит так:

Ваше приложение просто запрашивает базу данных и получает ее! Затем вы можете скопировать свое приложение в другое облако, и оно получит там другую базу данных!

Дело в том, что ваше приложение не запрашивает «базу данных», оно запрашивает базу данных MySQL Google Cloud Platform CloudSQL. Это не портативно! Надеюсь, что в будущем OSB API получит таксономию для общих типов, позволяющую вашему приложению просто запрашивать базу данных MySQL, а тип и размер будут автоматически определяться средой, в которой вы работаете, и некоторой политикой, установленной вашим администратор команды.

Теперь, даже если бы существовала таксономия для общих типов, Google, Microsoft и т. Д. Не подталкивают вас к использованию таких вещей, как MySQL через OSB API. Они хотят, чтобы вы использовали Bigtable вместо MySQL. Это видно на большинстве их примеров и в том порядке, в котором они реализуют услуги в своих брокерах услуг.

CoreOS также анонсировала свои Открытые облачные сервисы, которые, хотя и представляют собой каталог услуг, не используют OSB API.

CoreOS предлагает способ запуска и управления некоторыми популярными проектами с открытым исходным кодом в вашем кластере. Часть, которую предоставляет OSB API, минимальна для этого. На самом деле они конкурируют с чем-то вроде Ansible за правильные обновления и изменения работающих систем, а также с системными администраторами Real Human. Тем не менее, было бы неплохо, если бы Open Cloud Services могли использовать OSB API там, где это применимо.

Тенденции: сервисные сети

Фон

Перед мини-саммитом Istio во вторник я относился к служебным сеткам прохладно.

Рекламируемые преимущества, которые я слышал о сервисных сетках раньше, заключались в том, что, не внося изменений в свое приложение, вы автоматически получите:

  • телеметрия (время запроса, частота ошибок)
  • трассировка (запрос X прошел через службу Y, затем Z)
  • отказоустойчивость (повторные попытки и откат перед лицом ошибок удаленной службы)

Секрет в том, что вам действительно нужно изменить свое приложение, чтобы получить трассировку, а значимые данные телеметрии должны знать о некоторой информации на уровне приложения (отслеживание с помощью чистого URL-адреса бесполезно: большинство REST API имеют уникальные URL-адреса для каждой «вещи», которую они store. Вы хотите отслеживать все связанные вещи вместе).

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

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

Идентификация рабочей нагрузки (через SPIFFE) позволяет любой рабочей нагрузке (приложению) проверять личность отправителя запроса в пределах сервисной сети. Это означает, что микросервис billing может точно знать, что запросы, которые, по всей видимости, исходят от микросервиса store для поиска какого-либо клиента, на самом деле исходят от микросервиса store. Это может показаться простым, но сделать это автоматизированным способом, как известно, сложно. SPIFFE предоставляет образец для этого.

Поскольку Istio точно знает, какие две службы задействованы в запросе, на уровне контейнера приложения / докера и работая на уровне приложения, вы можете определять такие политики, как:

  • только микросервис store может создавать новые платежи в billing
  • только службе billing разрешено разговаривать с Stripe (исходящие правила на основе DNS)

Это довольно круто по сравнению с работой на уровне IP-адресов и только на портах!

Тренд

У нас даже появилась новая сервисная сетка! Анонсирован Conduit. Это от создателей Linkerd (одна из первых, если не первая, сервисных сеток). Для Conduit еще рано; вы не можете использовать его в продакшене, но вы, безусловно, можете внести значительный вклад в проект 🙂.

Помимо участия в переговорах, многие поставщики в зале демонстрировали возможности маршрутизации и политик прикладного уровня (уровень 7 в модели OSI) либо через Istio, либо через свои собственные решения. Если бы это было связано с сетевой безопасностью, кто-то утверждал, что сервисная сетка заменит ее.

Для подключения центров обработки данных не требуется VPN; используйте служебную сетку!

Выбросьте этот дорогой брандмауэр Barracuda; используйте служебную сетку!

Никакие претензии не были диковинными, но все волнующие и смелые претензии все же были немного забавными.

Я готов поспорить, что сервисные сети и их функции безопасности станут большой тенденцией в корпоративных продажах и услугах в ближайшие годы, вытеснив традиционное программное обеспечение / устройства межсетевых экранов и существующие продукты Software Defined Networking.

Тенденции: расширяемость Kubernetes

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

Только недавно расширяемость более высокого уровня стала в центре внимания (возможно, в течение последнего года), и только сейчас она становится пригодной для использования в таких вещах, как Custom Resource Definitions (которые мы используем для нашей интеграции Manifold kubernetes-credentials).

Раньше, если вы хотели расширить Kubernetes для добавления пользовательских функций, таких как новый тип рабочей нагрузки, вам нужно было форкнуть код, чтобы добавить его. Именно это сделала Red Hat с OpenShift (хотя, насколько я понимаю, они работают над извлечением своего уникального кода).

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

С другой стороны, немногие поставщики в зале или на переговорах в треке Расширение Kubernetes воспользовались преимуществами новых механизмов расширяемости, таких как CRD; большинство людей все еще создают сценарии помимо Kubernetes, а не логику, которая запускается внутри. Моя гипотеза состоит в том, что хотя большинство этих механизмов расширяемости, которые они могли бы использовать, очень новы, они их не используют, потому что пытаются поддерживать и другие системы, такие как Mesos и Docker Swarm.

Летучие мыши!

Вы знали, что в Остине есть гигантская колония летучих мышей под одним из мостов? Я не сделал! Мамы-летучие мыши приезжают в Остин из Мексики весной, рожают своих детенышей и растят летом на вкусных жуках Остина. К сожалению, мама и летучие мыши все улетели в Мексику до того, как я туда прилетел.

Еда!

Было здорово попробовать настоящее техасское барбекю. Это было очень вкусно, но после того, как я прожил в Роли, я всегда буду в первую очередь любителем барбекю из восточной Северной Каролины. Не могу побить этот уксусный соус!

KubeCon был прекрасным временем. Я с нетерпением жду того, что принесет Kubernetes следующий год, и надеюсь увидеть вас на KubeCon2018!