До Istio и по-нататък: Интерфейс на услугата Mesh на Azure

Съвременното разработване на първоначално облачно приложение, поне на Azure, стана почти зависимо от Kubernetes. Технологии като виртуални кубелети, AKS (Azure Kubernetes Service) и Azure Service Fabric Mesh са ключови за изграждането на мащабируеми разпределени приложения в Azure, като използват контейнери за разполагане и управление на микроуслуги.

Разглеждайки инструментите Kubernetes на Azure, става ясно, че Microsoft върши много работа в и около Cloud Native Computing Foundation, като работи по всички аспекти на рамката с отворен код. Не бива да се изненадваме; Microsoft нае един от основателите на проекта Kubernetes и след това придоби Deis, важен доставчик. Екипът на Deis стои зад един от последните приноси на Azure за екосистемата Kubernetes, Service Mesh Interface (SMI).

Представяме сервизни мрежи

Може би най-добре е първо да обясните какво представлява мрежова услуга и защо е важно за всяко приложение, базирано на Kubernetes.

Съвременните ИТ архитектури са свързани с абстракция. С облачните услуги вече не е нужно да мислим за основния хардуер. Ако използваме IaaS, дефинираме виртуални машини, които да хостват нашия код. С PaaS сме още по-далеч от хардуера, използвайки избраните от нас услуги и API, избирайки подходящо ниво на производителност за нашите приложения и бюджети. С базирани на контейнери архитектури като Kubernetes сме в точка някъде между двете: използвайки услуги като AKS, можем да дефинираме основните виртуални машини, които след това хостват нашите контейнери и се мащабират с промени в изчисленията и паметта сега с KEDA (базирано на Kubernetes автоматично управлявано от събития автоматично скалиране), при получаване на събития).

Това е само един аспект на абстракцията. Микроуслугите на Kubernetes са по същество без гражданство; те използват външно хранилище и седят на физическа или виртуална мрежа. Именно мрежовият аспект на стартирането на Kubernetes е може би най-сложният: Тъй като услугите се мащабират и намаляват, трябва да модифицирате мрежата си, за да съответства на промените във вашето приложение. Но как поддържате връзката на услугите, когато предната и задната част на приложението може да се мащабират с различни скорости?

Тук идват сервизните мрежи. Те са нов слой абстракция, който отклонява кода ви от основната мрежа, като се възползва от възможностите на модерна софтуерно дефинирана мрежа. Като действа като набор от мрежови прокси сървъри, които са внедрени с вашия код, мрежовата услуга управлява комуникацията между услугите, без вашият код да се нуждае от информираност за основната мрежа. Можете да мислите за сервизна мрежа като за автоматизирана равнина за управление на мрежата на вашето приложение, управляваща основната равнина на управление, докато Kubernetes мащабира вашия код нагоре и надолу.

Софтуерно дефинирана мрежа за микроуслуги

Може би най-добрият мисъл като начин за внедряване на интелигентно, съобразено със закъснението, мащабируемо балансиране на натоварването заедно с откриването на услугата, сервизната мрежа е основно разпределен рутер с правила за динамично маршрутизиране, които се управляват като част от внедряването на Kubernetes. Можете да дефинирате допълнителни правила; например, поддържане на отделни производствени и тестови системи или обработка на внедряването на нова версия и промяната между версиите на контейнера. Всяка подсистема в приложение има екземпляр на мрежов сервиз, който се изпълнява като страничен носач, с откриване на услуги и други елементи с състояние, работещи извън вашите услуги.

Със служебната мрежа вие прокарвате интелигентността в нов мрежов слой, така че не е нужно да я поставяте във вашите микроуслуги. Трябва да шифровате връзка? Това е работа за вашата мрежа за услуги. Трябва да упълномощите клиентите? Друга задача за сервизната мрежа.

Твърде много мрежи

Комбинирането на внедряване на Kubernetes със сервизна мрежа има много смисъл. Има обаче още един голям проблем: кой от тях използвате? Пратеник? Истио? Linkerd? Aspen Mesh? Ако сте избрали един, какво ще попречи на екипа за разработки в друга част от вашия бизнес да избере друг? Тогава какво се случва, ако вашата компания реши да стандартизира на определена платформа?

Това е проблемът, който Microsoft си поставя за разрешаване с интерфейса на Service Mesh. Вместо всяка услужна мрежа да има свой собствен набор от API, SMI е начин за внедряване на общи API, които работят в различни сервизни мрежи, управлявайки тази нова интелигентна мрежа. Вместо да заключвате кода си в конкретна услужна мрежа и нейните API, можете да напишете код, който адресира най-често използваните случаи чрез общ API. Ако трябва да замените мрежова услуга - ако смените доставчика или намерите такъв, който работи по-добре - няма нужда да променяте кода си, стига служебната мрежа да изпълнява SMI. Всичко, което трябва да направите, е да промените сервизните си странични коли и да преразпределите кода си.

SMI: често срещани приложни програмни интерфейси (API) на услугата

Работейки с Kubernetes-екосистемни компании като Hashicorp и Buoyant, Microsoft определя основните характеристики на SMI, които поддържат общи искания от своите клиенти. В първоначалната версия той се фокусира върху три области: политика на трафика, телеметрия на трафика и управление на трафика. Тези три области се контролират от повечето сервизни мрежи и намерението е да се направи това спецификация, която е лесна за изпълнение, без да се променя основното приложение.

Правейки SMI набор от стандартни API, няма нищо, което да попречи на доставчиците на мрежови мрежи да продължат да предлагат свои собствени API или допълнителни функции извън посочените. Като алтернатива те не трябва да правят промени; трети страни могат да изграждат слоеве за превод, които се намират между API на SMI и API на собствени услуги. Няма да ви е необходима и нова версия на Kubernetes, тъй като SMI API са внедрени като разширения API сървъри и дефиниции на персонализирани ресурси. Можете да продължите да ги инсталирате във всеки клъстер, като използвате съществуващите инструменти за управление. Това трябва да улесни SMI за Azure и други хоствани в облака услуги Kubernetes, за да ги вгради в съществуващите си управлявани услуги Kubernetes.

Независимо дали искате да използвате Linkerd или Aspen Mesh или NSX Service Mesh на VMware, с SMI ще можете да изберете този, който предпочитате, подобрявайки преносимостта на кода и избягвайки заключването на конкретни облачни услуги. Тогава има възможност да превключвате мрежи от услуги, без да засягате кода си. Ако нова услужна мрежа предлага по-добра производителност, всичко, което трябва да направите, е да промените своя компилационен конвейер, за да използвате новата мрежа и след това да внедрите актуализирано приложение.

Интересно е да видим как Microsoft поема водеща роля в подобен проект, като работи с широко напречно сечение на общността Kubernetes. Като възприема подход, който изрично не е фокусиран върху изграждането на мрежова услуга, Azure може да предложи различни сервизни мрежи като част от конфигурирането на AKS, позволявайки ви да изберете инструмента, който искате, без да е необходимо да променяте какъвто и да е код.