ໄຟລ໌ທ້ອງຖິ່ນເມື່ອຍ້າຍແອັບພລິເຄຊັນໄປ Kubernetes

ເມື່ອສ້າງຂະບວນການ CI / CD ໂດຍໃຊ້ Kubernetes, ບາງຄັ້ງບັນຫາເກີດຂື້ນຂອງຄວາມບໍ່ສອດຄ່ອງລະຫວ່າງຄວາມຕ້ອງການຂອງໂຄງສ້າງພື້ນຖານໃຫມ່ແລະຄໍາຮ້ອງສະຫມັກທີ່ຖືກໂອນໄປຫາມັນ. ໂດຍສະເພາະ, ໃນຂັ້ນຕອນການສ້າງຄໍາຮ້ອງສະຫມັກມັນເປັນສິ່ງສໍາຄັນທີ່ຈະໄດ້ຮັບ один ຮູບ​ພາບ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ໃນ​ всех ສະພາບແວດລ້ອມຂອງໂຄງການ ແລະກຸ່ມ. ຫຼັກການນີ້ເນັ້ນໃສ່ຄວາມຖືກຕ້ອງ ອີງຕາມ Google ການຈັດການຕູ້ຄອນເທນເນີ (ຫຼາຍກວ່າຫນຶ່ງຄັ້ງກ່ຽວກັບເລື່ອງນີ້ ເວົ້າ ແລະພະແນກວິຊາການຂອງພວກເຮົາ).

ຢ່າງໃດກໍ່ຕາມ, ທ່ານຈະບໍ່ເຫັນໃຜຢູ່ໃນສະຖານະການທີ່ລະຫັດຂອງເວັບໄຊທ໌ໃຊ້ກອບທີ່ກຽມພ້ອມ, ການນໍາໃຊ້ທີ່ກໍານົດຂໍ້ຈໍາກັດໃນການນໍາໃຊ້ຕໍ່ໄປ. ແລະໃນຂະນະທີ່ຢູ່ໃນ "ສະພາບແວດລ້ອມປົກກະຕິ" ນີ້ແມ່ນງ່າຍທີ່ຈະຈັດການກັບ, ໃນ Kubernetes ພຶດຕິກໍານີ້ສາມາດກາຍເປັນບັນຫາ, ໂດຍສະເພາະໃນເວລາທີ່ທ່ານພົບມັນຄັ້ງທໍາອິດ. ໃນຂະນະທີ່ຄວາມຄິດປະດິດສ້າງສາມາດມາເຖິງການແກ້ໄຂພື້ນຖານໂຄງລ່າງທີ່ເບິ່ງຄືວ່າຈະແຈ້ງຫຼືແມ້ກະທັ້ງທີ່ດີຢູ່ glance ທໍາອິດ ... ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ຈໍາວ່າສະຖານະການສ່ວນໃຫຍ່ສາມາດແລະຄວນ. ໄດ້ຮັບການແກ້ໄຂດ້ວຍຖາປັດຕະຍະ.

ຂໍໃຫ້ເບິ່ງວິທີການແກ້ໄຂບັນຫາທີ່ນິຍົມສໍາລັບການເກັບຮັກສາໄຟລ໌ທີ່ສາມາດນໍາໄປສູ່ຜົນສະທ້ອນທີ່ບໍ່ຫນ້າພໍໃຈໃນເວລາປະຕິບັດງານກຸ່ມ, ແລະຍັງຊີ້ໃຫ້ເຫັນເສັ້ນທາງທີ່ຖືກຕ້ອງກວ່າ.

ການເກັບຮັກສາຄົງທີ່

ເພື່ອສະແດງໃຫ້ເຫັນ, ພິຈາລະນາຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ໃຊ້ບາງປະເພດຂອງເຄື່ອງກໍາເນີດ static ເພື່ອໃຫ້ໄດ້ຮັບຊຸດຂອງຮູບພາບ, ຮູບແບບ, ແລະສິ່ງອື່ນໆ. ຕົວຢ່າງ, Yii PHP framework ມີຕົວຈັດການຊັບສິນທີ່ສ້າງຊື່ໄດເລກະທໍລີທີ່ເປັນເອກະລັກ. ຕາມນັ້ນແລ້ວ, ຜົນຜະລິດແມ່ນຊຸດຂອງເສັ້ນທາງສໍາລັບສະຖານທີ່ຄົງທີ່ແນ່ນອນບໍ່ຕັດກັນ (ນີ້ແມ່ນເຮັດດ້ວຍເຫດຜົນຫຼາຍຢ່າງ - ຕົວຢ່າງ, ເພື່ອລົບລ້າງການຊ້ໍາກັນເມື່ອຫຼາຍອົງປະກອບໃຊ້ຊັບພະຍາກອນດຽວກັນ). ດັ່ງນັ້ນ, ອອກຈາກກ່ອງ, ຄັ້ງທໍາອິດທີ່ທ່ານເຂົ້າເຖິງໂມດູນຊັບພະຍາກອນເວັບໄຊຕ໌, ໄຟລ໌ຄົງທີ່ (ໃນຄວາມເປັນຈິງ, ມັກຈະເປັນ symlinks, ແຕ່ຫຼາຍກວ່ານັ້ນຕໍ່ມາ) ຖືກສ້າງຕັ້ງຂຶ້ນແລະວາງອອກດ້ວຍລະບົບຮາກທົ່ວໄປທີ່ເປັນເອກະລັກສໍາລັບການນໍາໃຊ້ນີ້:

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

ນີ້ຫມາຍຄວາມວ່າແນວໃດໃນແງ່ຂອງກຸ່ມ?

ຕົວຢ່າງທີ່ງ່າຍດາຍທີ່ສຸດ

ໃຫ້ພິຈາລະນາກໍລະນີທີ່ພົບເລື້ອຍ, ເມື່ອ PHP ຖືກນໍາຫນ້າໂດຍ nginx ເພື່ອແຈກຢາຍຂໍ້ມູນສະຖິດແລະດໍາເນີນຄໍາຮ້ອງຂໍງ່າຍດາຍ. ວິ​ທີ​ທີ່​ງ່າຍ​ທີ່​ສຸດ - ການປະຕິບັດ ມີສອງຖັງ:

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

ໃນຮູບແບບທີ່ງ່າຍດາຍ, config 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. ແຕ່ໃນກໍລະນີຂອງສອງຖັງພາຍໃນຫນຶ່ງຝັກ, nginx ບໍ່ຮູ້ຫຍັງກ່ຽວກັບໄຟລ໌ຄົງທີ່ເຫຼົ່ານີ້, ເຊິ່ງ (ອີງຕາມການຕັ້ງຄ່າ) ຄວນຖືກມອບໃຫ້ພວກເຂົາ. ດັ່ງນັ້ນ, ລູກຄ້າຈະເຫັນຂໍ້ຜິດພາດ 404 ສໍາລັບການຮ້ອງຂໍທັງຫມົດກັບໄຟລ໌ CSS ແລະ JS. ການແກ້ໄຂທີ່ງ່າຍດາຍທີ່ສຸດຢູ່ທີ່ນີ້ແມ່ນການຈັດລະບຽບໄດເລກະທໍລີທົ່ວໄປສໍາລັບບັນຈຸ. ທາງເລືອກເບື້ອງຕົ້ນ - ທົ່ວໄປ 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 ຢ່າງຖືກຕ້ອງ. ແຕ່ໃຫ້ຂ້ອຍເຕືອນເຈົ້າວ່ານີ້ແມ່ນການແກ້ໄຂເບື້ອງຕົ້ນ, ຊຶ່ງຫມາຍຄວາມວ່າມັນຢູ່ໄກຈາກຄວາມເຫມາະສົມແລະມີ nuances ແລະຂໍ້ບົກຜ່ອງຂອງຕົນເອງ, ເຊິ່ງໄດ້ສົນທະນາຂ້າງລຸ່ມນີ້.

ບ່ອນຈັດເກັບຂໍ້ມູນຂັ້ນສູງ

ຕອນນີ້ຈິນຕະນາການສະຖານະການທີ່ຜູ້ໃຊ້ໄດ້ໄປຢ້ຽມຢາມເວັບໄຊທ໌, ໂຫລດຫນ້າທີ່ມີຮູບແບບທີ່ມີຢູ່ໃນຖັງ, ແລະໃນຂະນະທີ່ລາວກໍາລັງອ່ານຫນ້ານີ້, ພວກເຮົາໄດ້ນໍາໃຊ້ກ່ອງບັນຈຸໃຫມ່. ລາຍການຊັບສິນໄດ້ກາຍເປັນຫວ່າງເປົ່າແລະຄໍາຮ້ອງຂໍໄປຫາ PHP ແມ່ນຈໍາເປັນເພື່ອເລີ່ມຕົ້ນການສ້າງອັນໃຫມ່. ຢ່າງໃດກໍຕາມ, ເຖິງແມ່ນວ່າຫຼັງຈາກນັ້ນ, ການເຊື່ອມຕໍ່ກັບ statics ເກົ່າຈະບໍ່ກ່ຽວຂ້ອງ, ເຊິ່ງຈະນໍາໄປສູ່ຄວາມຜິດພາດໃນການສະແດງ statics.

ນອກຈາກນັ້ນ, ພວກເຮົາມີໂຄງການທີ່ໂຫລດຫຼາຍຫຼືຫນ້ອຍ, ຊຶ່ງຫມາຍຄວາມວ່າຫນຶ່ງສໍາເນົາຂອງຄໍາຮ້ອງສະຫມັກຈະບໍ່ພຽງພໍ:

• ໃຫ້ຂະຫຍາຍມັນຂຶ້ນ ການປະຕິບັດ ເຖິງສອງແບບຈໍາລອງ.
• ເມື່ອເວັບໄຊທ໌ໄດ້ເຂົ້າເຖິງຄັ້ງທໍາອິດ, ຊັບສິນໄດ້ຖືກສ້າງຂື້ນໃນຫນຶ່ງ replica.
• ໃນບາງຈຸດ, ingress ຕັດສິນໃຈ (ສໍາລັບຈຸດປະສົງການດຸ່ນດ່ຽງການໂຫຼດ) ເພື່ອສົ່ງຄໍາຮ້ອງຂໍໃຫ້ replica ທີສອງ, ແລະຊັບສິນເຫຼົ່ານີ້ຍັງບໍ່ທັນມີ. ຫຼືບາງທີພວກເຂົາບໍ່ມີຕໍ່ໄປອີກແລ້ວເພາະວ່າພວກເຮົາໃຊ້ RollingUpdate ແລະ​ໃນ​ປັດ​ຈຸ​ບັນ​ພວກ​ເຮົາ​ກໍາ​ລັງ​ດໍາ​ເນີນ​ການ​ນໍາ​ໃຊ້​.

ໂດຍທົ່ວໄປ, ຜົນໄດ້ຮັບແມ່ນຄວາມຜິດພາດອີກເທື່ອຫນຶ່ງ.

ເພື່ອຫຼີກເວັ້ນການສູນເສຍຊັບສິນເກົ່າ, ທ່ານສາມາດປ່ຽນແປງໄດ້ emptyDir ສຸດ hostPath, ການເພີ່ມ static ທາງດ້ານຮ່າງກາຍໃຫ້ກັບ node cluster. ວິທີການນີ້ແມ່ນບໍ່ດີເພາະວ່າຕົວຈິງແລ້ວພວກເຮົາຕ້ອງ ຜູກມັດກັບ node ກຸ່ມສະເພາະ ຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ເນື່ອງຈາກວ່າ - ໃນກໍລະນີຂອງການຍ້າຍໄປ nodes ອື່ນໆ - ໄດເລກະທໍລີຈະບໍ່ມີໄຟລ໌ທີ່ຈໍາເປັນ. ຫຼືບາງປະເພດຂອງການ synchronization ປະຫວັດຄວາມເປັນມາລະຫວ່າງ nodes ແມ່ນຕ້ອງການ.

ວິທີແກ້ໄຂແມ່ນຫຍັງ?

1. ຖ້າຮາດແວແລະຊັບພະຍາກອນອະນຸຍາດໃຫ້, ທ່ານສາມາດນໍາໃຊ້ cephfs ເພື່ອຈັດລະບຽບໄດເລກະທໍລີທີ່ສາມາດເຂົ້າເຖິງໄດ້ເທົ່າທຽມກັນສໍາລັບຄວາມຕ້ອງການຄົງທີ່. ເອກະສານທາງການ ແນະນໍາໃຫ້ SSD drives, ຢ່າງຫນ້ອຍການຈໍາລອງສາມເທົ່າແລະການເຊື່ອມຕໍ່ "ຫນາ" ທີ່ຫມັ້ນຄົງລະຫວ່າງ nodes cluster.
2. ທາງເລືອກທີ່ມີຄວາມຕ້ອງການຫນ້ອຍແມ່ນການຈັດລະບຽບເຄື່ອງແມ່ຂ່າຍ NFS. ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ພິຈາລະນາການເພີ່ມຂຶ້ນທີ່ເປັນໄປໄດ້ຂອງເວລາຕອບສະຫນອງສໍາລັບການດໍາເນີນການຮ້ອງຂໍໂດຍເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, ແລະຄວາມທົນທານຕໍ່ຄວາມຜິດຈະປ່ອຍໃຫ້ຫຼາຍທີ່ຈະຕ້ອງການ. ຜົນສະທ້ອນຂອງຄວາມລົ້ມເຫຼວແມ່ນໄພພິບັດ: ການສູນເສຍຂອງ mount dooms ກຸ່ມການເສຍຊີວິດພາຍໃຕ້ຄວາມກົດດັນຂອງການໂຫຼດ LA rushing ເຂົ້າໄປໃນທ້ອງຟ້າ.

ໃນບັນດາສິ່ງອື່ນໆ, ທາງເລືອກທັງຫມົດສໍາລັບການສ້າງບ່ອນເກັບມ້ຽນຄົງຈະຕ້ອງການ ທໍາ​ຄວາມ​ສະ​ອາດ​ພື້ນ​ຖານ​ ຊຸດໄຟລ໌ທີ່ລ້າສະໄຫມສະສົມໃນໄລຍະເວລາທີ່ແນ່ນອນ. ຢູ່ທາງຫນ້າຂອງບັນຈຸທີ່ມີ PHP ທ່ານສາມາດໃສ່ DaemonSet ຈາກ caching nginx, ເຊິ່ງຈະເກັບຮັກສາສໍາເນົາຊັບສິນໃນໄລຍະເວລາຈໍາກັດ. ພຶດ​ຕິ​ກໍາ​ນີ້​ແມ່ນ​ກໍາ​ນົດ​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ໂດຍ​ນໍາ​ໃຊ້​ proxy_cache ດ້ວຍຄວາມເລິກຂອງການເກັບຮັກສາໃນມື້ຫຼື gigabyte ຂອງພື້ນທີ່ດິດ.

ການລວມເອົາວິທີການນີ້ກັບລະບົບໄຟລ໌ແຈກຢາຍທີ່ໄດ້ກ່າວມາຂ້າງເທິງນີ້ສະຫນອງພາກສະຫນາມຂະຫນາດໃຫຍ່ສໍາລັບການຈິນຕະນາການ, ຈໍາກັດພຽງແຕ່ງົບປະມານແລະທ່າແຮງດ້ານວິຊາການຂອງຜູ້ທີ່ຈະປະຕິບັດແລະສະຫນັບສະຫນູນມັນ. ຈາກປະສົບການ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າລະບົບທີ່ງ່າຍດາຍຫຼາຍ, ມັນເຮັດວຽກທີ່ຫມັ້ນຄົງຫຼາຍ. ເມື່ອຊັ້ນດັ່ງກ່າວຖືກເພີ່ມ, ມັນຈະກາຍເປັນຄວາມຫຍຸ້ງຍາກຫຼາຍໃນການຮັກສາໂຄງສ້າງພື້ນຖານ, ແລະໃນເວລາດຽວກັນທີ່ໃຊ້ເວລາໃນການວິນິດໄສແລະການຟື້ນຕົວຈາກຄວາມລົ້ມເຫລວໃດໆກໍ່ເພີ່ມຂຶ້ນ.

ຂໍ້ສະ ເໜີ ແນະ

ຖ້າການປະຕິບັດທາງເລືອກການເກັບຮັກສາທີ່ສະເຫນີຍັງເບິ່ງຄືວ່າບໍ່ຍຸຕິທໍາກັບທ່ານ (ສັບສົນ, ລາຄາແພງ ...), ມັນຄວນຈະເບິ່ງສະຖານະການຈາກອີກດ້ານຫນຶ່ງ. ຄື, ການຂຸດເຂົ້າໄປໃນສະຖາປັດຕະໂຄງການແລະ ແກ້ໄຂບັນຫາໃນລະຫັດ, ຜູກມັດກັບໂຄງສ້າງຂໍ້ມູນສະຖິດຢູ່ໃນຮູບພາບ, ຄໍານິຍາມທີ່ບໍ່ຊັດເຈນຂອງເນື້ອໃນຫຼືຂັ້ນຕອນສໍາລັບ "ການອົບອຸ່ນຂຶ້ນ" ແລະ / ຫຼື precompiling ຊັບສິນໃນຂັ້ນຕອນການປະກອບຮູບພາບ. ວິທີນີ້ພວກເຮົາໄດ້ຮັບພຶດຕິກໍາທີ່ຄາດເດົາໄດ້ຢ່າງແທ້ຈິງແລະຊຸດໄຟລ໌ດຽວກັນສໍາລັບສະພາບແວດລ້ອມທັງຫມົດແລະການຈໍາລອງຂອງແອັບພລິເຄຊັນທີ່ເຮັດວຽກ.

ຖ້າພວກເຮົາກັບຄືນໄປຫາຕົວຢ່າງສະເພາະກັບກອບ Yii ແລະບໍ່ເຂົ້າໃຈໂຄງສ້າງຂອງມັນ (ເຊິ່ງບໍ່ແມ່ນຈຸດປະສົງຂອງບົດຄວາມ), ມັນພຽງພໍທີ່ຈະຊີ້ໃຫ້ເຫັນສອງວິທີການທີ່ນິຍົມ:

1. ປ່ຽນຂະບວນການສ້າງຮູບພາບເພື່ອວາງຊັບສິນໃນສະຖານທີ່ທີ່ຄາດເດົາໄດ້. ນີ້ແມ່ນແນະນໍາ / ປະຕິບັດໃນສ່ວນຂະຫຍາຍເຊັ່ນ yii2-static-ຊັບສິນ.
2. ກໍານົດ hashes ສະເພາະສໍາລັບລາຍການຊັບສິນ, ດັ່ງທີ່ໄດ້ສົນທະນາໃນຕົວຢ່າງເຊັ່ນ. ການນໍາສະເຫນີນີ້ (ເລີ່ມຈາກສະໄລ້ທີ 35). ໂດຍວິທີທາງການ, ຜູ້ຂຽນບົດລາຍງານໃນທີ່ສຸດ (ແລະບໍ່ແມ່ນບໍ່ມີເຫດຜົນ!) ແນະນໍາວ່າຫຼັງຈາກການປະກອບຊັບສິນໃນເຊີຟເວີກໍ່ສ້າງ, ອັບໂຫຼດພວກມັນໃສ່ບ່ອນເກັບມ້ຽນກາງ (ເຊັ່ນ S3), ຢູ່ທາງຫນ້າຂອງສະຖານທີ່ CDN.

ດາວໂຫຼດ

ອີກກໍລະນີທີ່ຈະເຂົ້າມາຫຼິ້ນຢ່າງແນ່ນອນເມື່ອຍ້າຍແອັບພລິເຄຊັນໄປຫາກຸ່ມ Kubernetes ແມ່ນການເກັບຮັກສາໄຟລ໌ຜູ້ໃຊ້ຢູ່ໃນລະບົບໄຟລ໌. ຕົວຢ່າງ, ພວກເຮົາມີຄໍາຮ້ອງສະຫມັກ PHP ອີກເທື່ອຫນຶ່ງທີ່ຍອມຮັບໄຟລ໌ຜ່ານແບບຟອມອັບໂຫລດ, ເຮັດບາງສິ່ງບາງຢ່າງກັບພວກເຂົາໃນລະຫວ່າງການປະຕິບັດງານ, ແລະສົ່ງຄືນ.

ໃນ Kubernetes, ສະຖານທີ່ບ່ອນທີ່ໄຟລ໌ເຫຼົ່ານີ້ຄວນຈະຖືກວາງໄວ້ຄວນຈະເປັນທົ່ວໄປກັບທຸກຕົວແບບຂອງແອັບພລິເຄຊັນ. ອີງຕາມຄວາມສັບສົນຂອງຄໍາຮ້ອງສະຫມັກແລະຄວາມຕ້ອງການໃນການຈັດຕັ້ງການຄົງຕົວຂອງໄຟລ໌ເຫຼົ່ານີ້, ທາງເລືອກອຸປະກອນທີ່ໃຊ້ຮ່ວມກັນຂ້າງເທິງອາດຈະເປັນສະຖານທີ່ດັ່ງກ່າວ, ແຕ່, ດັ່ງທີ່ພວກເຮົາເຫັນ, ມັນມີຂໍ້ບົກຜ່ອງຂອງພວກເຂົາ.

ຂໍ້ສະ ເໜີ ແນະ

ການແກ້ໄຂຫນຶ່ງແມ່ນ ໃຊ້ບ່ອນຈັດເກັບຂໍ້ມູນທີ່ເຂົ້າກັນໄດ້ກັບ S3 (ເຖິງແມ່ນວ່າມັນເປັນບາງປະເພດທີ່ເປັນເຈົ້າພາບຂອງຕົນເອງເຊັ່ນ minio). ການປ່ຽນເປັນ S3 ຈະຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງ ໃນລະດັບລະຫັດ, ແລະວິທີການເນື້ອຫາຈະຖືກສົ່ງຢູ່ດ້ານຫນ້າ, ພວກເຮົາມີຢູ່ແລ້ວ wrote.

ຊ່ວງເວລາຂອງຜູ້ໃຊ້

ແຍກຕ່າງຫາກ, ມັນເປັນມູນຄ່າບອກອົງການຈັດຕັ້ງການເກັບຮັກສາຂອງກອງປະຊຸມຜູ້ໃຊ້. ເລື້ອຍໆສິ່ງເຫຼົ່ານີ້ຍັງເປັນໄຟລ໌ຢູ່ໃນແຜ່ນ, ເຊິ່ງໃນສະພາບການຂອງ Kubernetes ຈະນໍາໄປສູ່ການຮ້ອງຂໍການອະນຸຍາດຢ່າງຕໍ່ເນື່ອງຈາກຜູ້ໃຊ້ຖ້າຄໍາຮ້ອງຂໍຂອງລາວສິ້ນສຸດລົງໃນຖັງອື່ນ.

ບັນຫາແມ່ນໄດ້ຮັບການແກ້ໄຂບາງສ່ວນໂດຍການເປີດ stickySessions ຢູ່ໃນຂາເຂົ້າ (ຄຸນນະສົມບັດແມ່ນສະຫນັບສະຫນູນໃນຕົວຄວບຄຸມ ingress ທີ່ນິຍົມທັງຫມົດ - ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ, ເບິ່ງ ການທົບທວນຄືນຂອງພວກເຮົາ)ເພື່ອຜູກມັດຜູ້ໃຊ້ກັບພອດສະເພາະກັບແອັບພລິເຄຊັນ:

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 ແລະວິທີແກ້ໄຂທີ່ຄ້າຍຄືກັນ - ໂດຍ​ທົ່ວ​ໄປ​, ຫມົດ​ປະ​ຖິ້ມ​ທາງ​ເລືອກ​ໄຟລ​໌​.

ສະຫລຸບ

ການແກ້ໄຂພື້ນຖານໂຄງລ່າງທີ່ສົນທະນາຢູ່ໃນຂໍ້ຄວາມແມ່ນສົມຄວນທີ່ຈະໃຊ້ໃນຮູບແບບຂອງ "crutches" ຊົ່ວຄາວເທົ່ານັ້ນ (ເຊິ່ງສຽງທີ່ສວຍງາມກວ່າໃນພາສາອັງກິດເປັນການແກ້ໄຂ). ພວກມັນອາດຈະມີຄວາມກ່ຽວຂ້ອງໃນຂັ້ນຕອນທໍາອິດຂອງການເຄື່ອນຍ້າຍແອັບພລິເຄຊັນໄປຫາ Kubernetes, ແຕ່ບໍ່ຄວນຮາກ.

ເສັ້ນທາງທີ່ແນະນໍາໂດຍທົ່ວໄປແມ່ນເພື່ອກໍາຈັດພວກມັນອອກໃນເງື່ອນໄຂຂອງການແກ້ໄຂສະຖາປັດຕະຍະກໍາຂອງຄໍາຮ້ອງສະຫມັກທີ່ສອດຄ່ອງກັບສິ່ງທີ່ຫຼາຍຄົນຮູ້ຈັກແລ້ວ. 12-Factor App. ຢ່າງໃດກໍຕາມ, ນີ້ - ການນໍາເອົາຄໍາຮ້ອງສະຫມັກໄປສູ່ຮູບແບບທີ່ບໍ່ມີລັດ - inevitably ຫມາຍຄວາມວ່າການປ່ຽນແປງໃນລະຫັດຈະຕ້ອງ, ແລະໃນທີ່ນີ້ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຊອກຫາຄວາມສົມດູນລະຫວ່າງຄວາມສາມາດ / ຄວາມຕ້ອງການຂອງທຸລະກິດແລະຄວາມສົດໃສດ້ານໃນການປະຕິບັດແລະຮັກສາເສັ້ນທາງທີ່ເລືອກ. .

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «Proxying ໄຟລ໌ຈາກ AWS S3 ໂດຍໃຊ້ nginx"
• «7 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການນໍາໃຊ້ containers ອີງຕາມ Google"
• «7 ຫຼັກການໃນການອອກແບບຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ໃນຕູ້ຄອນເທນເນີ» (ຈາກ Red Hat);
• «7 ປັດໄຈທີ່ຂາດຫາຍໄປໃນ 12 ປັດໄຈ App".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com