🥇Локални файлове при прехвърляне на приложение в Kubernetes

При изграждането на процеса CI/CD с използване на Kubernetes понякога възниква проблем с несъвместимостта на изискванията на новата инфраструктура и пренасеното в нея приложение. В частност, на етапа на изграждане на приложението е важно да се получи един образ, който ще бъде използван в всички средите и клъстерите на проекта. Този принцип е в основата на правилното управление на контейнери според Google (неведнъж е ставало дума за това в нашия технически отдел). каза и нашият технически директор).

Въпреки това, няма да видите ситуации, в които в кода на сайта се използва готов фреймворк, чийто употреба налага ограничения на разширената му експлоатация. И ако в «обикновена среда» с това е лесно да се справите, в Kubernetes такова поведение може да се окаже проблем, особено когато се сблъсквате с него за пръв път. Въпреки че изобретателният ум може да предложи инфраструктурни решения, които изглеждат очевидни и дори добри на пръв поглед… е важно да запомните, че повечето ситуации могат и трябва да бъдат решавани архитектурно.

Нека разгледаме популярни workaround решения за съхранение на файлове, които могат да доведат до неприятни последици при експлоатацията на клъстера, а също така ще посочим по-правилния път.

Съхранение на статика

За илюстрация нека разгледаме уеб приложение, което използва някакъв генератор на статика за получаване на набор от изображения, стилове и други. Например, в PHP фреймворка Yii има вграден мениджър на активите, който генерира уникални наименования на директории. Съответно, на изхода получаваме набор от пътища за статика на сайта, които категорично не се пресичат (това е направено по няколко причини — например, за да се избегнат дубликати при употребата на един и същ ресурс от множество компоненти). Така, по подразбиране, при първото обръщение към модула на уеб ресурса, се формира и разпределя статиката (в действителност — често символични линкове, но за това по-късно) с уникален за това разгръщане общ корен каталог:

webroot/assets/2072c2df/css/…
webroot/assets/2072c2df/images/…
webroot/assets/2072c2df/js/…

С какви последствия може да се сблъскате в контекста на клъстера?

Прост пример

Нека вземем доста разпространен случай, когато пред PHP стои nginx за раздаване на статика и обработка на прости заявки. Най-простият начин е Deployment с два контейнера:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

В простом изложении конфигурация nginx выглядит следующим образом:

apiVersion: v1
kind: ConfigMap
metadata:
  name: "nginx-configmap"
data:
  nginx.conf: |
    server {
        listen 80;
        server_name _;
        charset utf-8;
        root  /var/www;

        access_log /dev/stdout;
        error_log /dev/stderr;

        location / {
            index index.php;
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi_params;
        }
    }

При первом запросе к сайту в контейнере с PHP появляются ассеты. Но в случае с двумя контейнерами в одном pod’е — nginx не знает о статических файлах, которые (согласно конфигурации) должны обрабатываться именно им. В результате на все запросы к CSS- и JS-файлам клиент получает ошибку 404. Простое решение — создать общую директорию для контейнеров. Примитивный вариант — общий emptyDir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: site
spec:
  selector:
    matchLabels:
      component: backend
  template:
    metadata:
      labels:
        component: backend
    spec:
      volumes:
        - name: assets
          emptyDir: {}
        - name: nginx-config
          configMap:
            name: nginx-configmap
      containers:
      - name: php
        image: own-image-with-php-backend:v1.0
        command: ["/usr/local/sbin/php-fpm","-F"]
        workingDir: /var/www
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
      - name: nginx
        image: nginx:1.16.0
        command: ["/usr/sbin/nginx", "-g", "daemon off;"]
        volumeMounts:
        - name: assets
          mountPath: /var/www/assets
        - name: nginx-config
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf

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

Более продвинутое хранилище

Сега да си представим ситуация, в която потребителят е влязъл на сайта, заредил страницата със стиловете, налични в контейнера, а докато чете страницата, ние отново преизтегляме контейнера. В каталога с активи стана пусто и е необходима заявка към PHP, за да стартира генерирането на нови. Въпреки това, дори и след това, връзките към старата статичност ще бъдат неактуални, което ще доведе до грешки в показването на статиката.

Освен това, най-вероятно имаме сравнително натоварен проект, а това означава, че една копия на приложението няма да е достатъчна:

Масштабиране Deployment до две реплики.
При първото обръщение към сайта в една реплика бяха създадени активи.
В определен момент ingress реши (в името на балансирането на натоварването) да изпрати заявка към втора реплика, а там тези активи още ги няма. Или може би там вече ги няма, защото използваме RollingUpdate и в момента правим деплой.

Общо взето, резултатът е отново грешки.

За да не загубим старите активи, можем да променим emptyDir на hostPath, като физически складираме статиката на възела в клъстера. Този подход е лош, защото в действителност трябва да се свържем с конкретен възел на клъстера с приложението си, тъй като при пренос на други възли директорията няма да съдържа необходимите файлове. Или е нужна някаква фонова синхронизация на директорията между възлите.

Какви са възможните решения?

Ако хардуерът и ресурсите позволяват, можем да използваме cephfs за организиране на равнодостъпна директория за нуждата от статиката. Официална документация препоръчва SSD дискове, минимум трикратна репликация и надеждно "дебело" свързване между възлите на клъстера.
По-малко взискателен вариант би бил организирането на NFS сървър. Въпреки това, трябва да се има предвид възможното повишаване на времето за отговор при обработка на заявки от уеб сървъра, а и устойчивостта при отказ ще остане желателна. Последствията от отказа са катастрофални: загубата на mount'а обрича клъстера на гибел под натиска на натоварването LA, стремящо се към небето.

Освен всичко друго, за всички варианти за създаване на постоянно хранилище ще е необходима фонова чистка на остарели набори файлове, натрупани за определен период от време. Преди контейнерите с PHP можем да поставим DaemonSet кеширащи nginx, които ще съхраняват копията на активите за ограничен период от време. Това поведение лесно се конфигурира с помощта на proxy_cache с с дълбочина на съхранение в дни или гигабайти дисково пространство.

Комбинирането на този метод с посочените по-горе разпределени файлови системи предоставя огромно поле за въображение, като единственото ограничение е бюджетът и техническите възможности на онези, които ще го реализират и поддържат. Накратко, колкото по-проста е системата, толкова по-стабилно работи. Добавянето на подобни слоеве прави поддръжката на инфраструктурата много по-трудна, а с това увеличава и времето, необходимо за диагностика и възстановяване при всякакви неизправности.

Препоръка

Ако реализирането на предложените варианти за хранилища ви изглежда неоправдано (сложно, скъпо...), заслужава да погледнете ситуацията от друг ъгъл. А именно — да се задълбочите в архитектурата на проекта и да премахнете проблема от кода, свързвайки се с някаква статична структура от данни в образа, недвусмислено определяне на съдържанието или процедурата на "подгряване" и/или прекомпилиране на активите на етапа на изграждане на образа. Така получаваме абсолютно предсказуемо поведение и еднакъв набор от файлове за всички среди и реплики на активираното приложение.

Ако се върнем към конкретния пример с фреймуърка Yii и не се задълбочаваме в неговата структура (що не е целта на статията), достатъчно е да посочим два популярни подхода:

Да се промени процесът на изграждане на образа, за да се поставят активите на предсказуемо място. Така предлагат/реализират в разширения като yii2-static-assets.
Да се определят конкретни хешове за директориите на активите, както се описва, например, в тази презентация (започвайки от слайд №35). Между другото, авторът на доклада в крайна сметка (и не без основание!) препоръчва след изграждане на активите на build-сървъра да ги зареди в централно хранилище (като S3), пред което да постави CDN.

Зареждаеми файлове

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

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

Препоръка

Един от вариантите за решение е използването на S3-съвместимо хранилище (дори и някакъв вариант от категория self-hosted като minio). Преходът към работа с S3 ще изисква промени на ниво код, а как ще протича доставката на съдържание на фронтенда, вече писахме.

Потребителски сесии

Отделно трябва да се отбележи организацията на съхранение на потребителски сесии. Често това също са файлове на диска, което в контекста на Kubernetes ще доведе до постоянни заявки за авторизация от потребителя, ако неговата заявка попадне в друг контейнер.

Отчасти проблемът се решава с активирането на stickySessions на ingress (функцията се поддържа във всички популярни контролери ingress — по-подробно вижте в нашия обзор), за да се свърже потребителят с конкретен pod с приложението:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"

spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

Но това няма да освободи от проблемите при повторни деплойменти.

Препоръка

По-правилният начин ще бъде преходът на приложението към съхранение на сесии в memcached, Redis и подобни решения — по принцип, напълно да се откаже от файловите варианти.

Заключение

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

Общият препоръчителен път е да се откажете от тях в полза на архитектурно адаптиране на приложението в съответствие с вече добре известния на много хора 12-Factor App. Въпреки това — адаптирането на приложението към stateless вид — неизбежно означава, че ще са необходими промени в кода, и тук е важно да се намери баланс между възможностите/изискванията на бизнеса и перспективите за реализация и поддръжка на избрания път.