Това е финалът на Kubecon 2018 и на 2018 като цяло. Докато размишлявам върху изживяването на Kubecon, изпъква един въпрос: трябва ли разработчиците на приложения да са наясно с Kubernetes?

Чух този въпрос да задават както клъстерни оператори, разработчици, така и доставчици. Резултатът от този дебат ще оформи бъдещето на Kubernetes. Нека да разгледаме двете страни на този дебат, с поглед към тенденциите, които съм наблюдавал през кариерата си като инфраструктурен инженер.

Kubernetes е детайл от изпълнението: скрийте го

Kubernetes предоставя много повече функционалност, отколкото вашият средностатистически програмист всъщност се нуждае. Работя с Kubernetes от година и на ум мога да назова само 8 вида обекти от около 50 общо. (За контекст, k3s е минимална дистрибуция на Kubernetes, която намали огромен брой функции и работи добре с повечето приложения на Kubernetes.) Разработчиците не се интересуват колко копия на тяхната услуга се изпълняват или какви Roles има, или дали работи чрез StatefulSets; всичко, от което се интересуват, е поставянето на HTTP крайна точка, която помага за доставянето на продукт. В резултат на това някои оператори избират да скрият Kubernetes в CI/CD тръбопровода. Разработчиците не се затъват от детайлите на k8s; те просто изпращат код към GitHub и останалото се поема вместо тях.

Дори ако разработчиците владеят добре Kubernetes, операторите може да не са склонни да им предоставят неограничен достъп до клъстер, тъй като малките промени могат да имат огромни вълнообразни ефекти. (Например: промените в ограниченията на ресурсите за Pod или Container могат да причинят проблеми с други внедрявания, които са планирани за същите възли.) В много организации операторите ще осигурят междинен слой, или с DSL, или отделен API, за да ограничат какво разработчиците могат да променят и поддържат по-строг контрол на клъстера.

Kubernetes е лингва франка на инфраструктурата: разкрийте я

Разработчиците вече не само пишат код на приложения. Тъй като нашата индустрия се придвижва повече към микроуслуги, разработчиците са овластени (и се очаква) да вземат повече инфраструктурни решения — и след това трябва да изградят и поддържат тази инфраструктура.

Kubernetes бързо се превръща в де факто начин за определяне на инфраструктура. Всичко, от което се нуждае една система – включително процеси, балансьори на натоварването и графични процесори – вече може да бъде артикулирано в YAML и планирано чрез Kubernetes. Тъй като Kubernetes става все по-разпространен, разработчиците ще напишат тонове документация, от уроци до отговори за препълване на стека, което го прави начинът да се направи инфраструктурата ясна. Виждаме това днес с Dockerfiles. Преди няколко години инструкциите за инсталиране на инструмент за разработчици вероятно съдържаха набор от apt-get команди. Днес цялата тази специфична за средата настройка е заменена от една единствена команда docker run.

Като човек, който е работил на места с домашни оркестратори на контейнери и ORM, знам от първа ръка, че възможностите на Google, които предоставя стандартизацията, са безценни.

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

С поглед към историята

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

Припомням си трансформацията, през която преминахме преди няколко години с Docker. Преди Docker идеята за зависимости за приложения стигаше само до зависимостите на кода: първо бяха .deb пакети, които гарантираха, че ImageMagick е инсталиран; след това бяха Gemfiles и package.jsons, които направиха собственото управление на зависимостите по-лесно. В крайна сметка разбрахме, че има други косвени зависимости, които не са описани, като версията на ядрото или оформлението на файловата система. Няма нищо по-разочароващо от това да стартирате gdb за диагностициране на проблем в производството само за да откриете, че версията на ядрото е различна от кутия до кутия. Dockerfiles най-накрая ни позволи да посочим тези зависимости на системно ниво.

Днес се нуждаем от подобен прост начин за изразяване на зависимостите на услугата. Дори за основно приложение LAMP, съобщаването на колегите, че сте добавили зависимост от Redis, е упражнение за безмилостно повторение. В организация от 100 инженери със сложно приложение за микроуслуги, промяната на топологията може да означава дни наред да помагате на младши инженери да отстраняват грешки в техните повредени среди за разработка. Имаме нужда от Dockerfile, но за микроуслуги; и докато можете да си представите вселена, в която операторите обработват всички Dockerfiles и разработчиците пазят ръцете си напълно чисти, е много по-лесно да пишете код и да отстранявате грешки, когато можете да разберете поне малко от това, което се случва във вашия Dockerfile. По същия начин, какъвто и да е нашият нов начин за определяне на услугите и техните зависимости, разработчиците ще го научат и ще се възползват от него, за да получат повече влияние над своите все по-сложни среди.

Точно както Docker превърна пространствата от имена и cgroups в удобен за потребителя продукт, нещо трябва да прерасне Kubernetes до удобна за потребителя рамка на зависимостта на услугите.

С поглед към бъдещето

Чувал съм да казват, че Kubernetes прави лесните неща трудни и трудните неща възможни. Това важи както за производството, така и за разработката. Например: лесно е да се направи изключително достъпно приложение без състояние на Kubernetes, но е сравнително трудно да се направи нещо просто като получаване на грешките за под.

Искаме да поправим това и започваме с „Накланяне“. Tilt ви позволява да развивате всичките си микроуслуги локално в Kubernetes, докато си сътрудничите с екипа си.

„Tilt“ улеснява общите задачи за разработка. Той не третира Kubernetes като черна кутия, нито ви принуждава да се тревожите за ConfigMaps в ежедневието си. По-скоро Tilt третира Kubernetes като сива кутия. Той предлага опростен, практичен интерфейс, който не ви ограничава да копаете в API, когато имате нужда.

Ако всички клъстерни оператори решат утре, че разработчиците никога не трябва да докосват Kubernetes, ние все още смятаме, че Tilt ще бъде полезен за много хора: но не виждам това да се случва. Софтуерът става твърде сложен и бизнес изискванията се развиват твърде бързо, за да изолират напълно разработчиците от инфраструктурата. Трябва да прегърнем сложността.