По правилу, увек постоји потреба да се апликацији обезбеди наменски скуп ресурса за њен исправан и стабилан рад. Али шта ако неколико апликација ради на истој снази? Како сваком од њих обезбедити минимум неопходних ресурса? Како можете ограничити потрошњу ресурса? Како правилно распоредити оптерећење између чворова? Како осигурати да механизам хоризонталног скалирања ради ако се оптерећење апликације повећа?
Морате почети од тога које главне врсте ресурса постоје у систему - ово је, наравно, време процесора и РАМ. У манифестима к8с ови типови ресурса се мере у следећим јединицама:
- ЦПУ - у језгрима
- РАМ - у бајтовима
Штавише, за сваки ресурс могуће је поставити две врсте захтева - Захтеви и ограничења. Захтеви – описује минималне захтеве за слободне ресурсе чвора за покретање контејнера (и под као целине), док ограничења постављају строго ограничење ресурса доступних контејнеру.
Важно је схватити да манифест не мора експлицитно да дефинише оба типа, али ће понашање бити следеће:
- Ако су само ограничења ресурса експлицитно наведена, онда захтеви за овај ресурс аутоматски узимају вредност једнаку ограничењима (ово можете да проверите позивањем десцрибе ентитета). Оне. у ствари, контејнер ће бити ограничен на исту количину ресурса потребних за покретање.
- Ако су само захтеви експлицитно наведени за ресурс, онда се за овај ресурс не постављају горња ограничења – тј. контејнер је ограничен само ресурсима самог чвора.
Такође је могуће конфигурисати управљање ресурсима не само на нивоу одређеног контејнера, већ и на нивоу именског простора користећи следеће ентитете:
- ЛимитРанге — описује политику ограничења на нивоу контејнера/макера у нс и потребна је да би се описали подразумевана ограничења на контејнеру/махуни, као и да би се спречило стварање очигледно дебелих контејнера/махуна (или обрнуто), ограничи њихов број и одредити могућу разлику у вредностима у границама и захтевима
- РесоурцеКуотас — описати политику ограничења уопште за све контејнере у нс и користи се, по правилу, за разграничење ресурса између окружења (корисно када окружења нису стриктно разграничена на нивоу чвора)
Следе примери манифеста који постављају ограничења ресурса:
-
На нивоу одређеног контејнера:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mОне. у овом случају, да бисте покренули контејнер са нгинк-ом, биће вам потребно најмање 1Г слободне РАМ-а и 0.2 ЦПУ-а на чвору, док контејнер може да потроши највише 0.2 ЦПУ-а и сву расположиву РАМ меморију на чвору.
-
На нивоу целог броја нс:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiОне. збир свих контејнера захтева у подразумеваним нс не може прећи 300м за ЦПУ и 1Г за ОП, а збир свих ограничења је 700м за ЦПУ и 2Г за ОП.
-
Подразумевана ограничења за контејнере у нс:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4GiОне. у подразумеваном именском простору за све контејнере, захтев ће бити постављен на 100м за ЦПУ и 1Г за ОП, ограничење - 1 ЦПУ и 2Г. Истовремено, постављено је и ограничење на могуће вредности у захтеву/ограничењу за ЦПУ (50м < к < 2) и РАМ (500М < к < 4Г).
-
Ограничења на нивоу подова нс:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiОне. за сваки под у подразумеваном нс биће ограничење од 4 вЦПУ и 1Г.
Сада бих желео да вам кажем које предности нам може дати постављање ових ограничења.
Механизам за балансирање оптерећења између чворова
Као што знате, компонента к8с је одговорна за дистрибуцију подова међу чворовима, као нпр сцхедулер, који ради по одређеном алгоритму. Овај алгоритам пролази кроз две фазе приликом избора оптималног чвора за покретање:
- филтрирање
- Рангинг
Оне. према описаној политици иницијално се бирају чворови на којима је могуће покренути под на основу скупа предикати (укључујући проверу да ли чвор има довољно ресурса за покретање под - ПодФитсРесоурцес), а затим за сваки од ових чворова, према приоритети додељују се поени (укључујући, што више слободних ресурса има чвор, то му је додељено више поена - ЛеастРесоурцеАллоцатион/ЛеастРекуестедПриорити/БаланцедРесоурцеАллоцатион) и модул се покреће на чвору са највише поена (ако неколико чворова истовремено испуњава овај услов, онда одабран је случајни) .
Истовремено, морате схватити да се планер, када процењује расположиве ресурсе чвора, руководи подацима који се чувају у етцд-у - тј. за износ захтеваног/ограниченог ресурса за сваки под који ради на овом чвору, али не и за стварну потрошњу ресурса. Ове информације се могу добити из излаза команде kubectl describe node $NODE, на пример:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)Овде видимо све подове који раде на одређеном чвору, као и ресурсе које сваки под захтева. А ево како изгледа евиденција планера када се покрене цроњоб-црон-евентс-1573793820-кт6к9 под (ове информације ће се појавити у евиденцији планера када поставите 10. ниво евидентирања у аргументима команде за покретање -в=10):
Пријава
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10Овде видимо да у почетку планер филтрира и генерише листу од 3 чвора на којима може да се покрене (нкс-к8с-с8, нкс-к8с-с9, нкс-к8с-с10). Затим израчунава резултате на основу неколико параметара (укључујући БаланцедРесоурцеАллоцатион, ЛеастРесоурцеАллоцатион) за сваки од ових чворова како би одредио најпогоднији чвор. Коначно, под је заказан на чвору са највећим бројем поена (овде два чвора имају исти број поена 100037, па је одабран случајни - нкс-к8с-с10).
Излаз: ако чвор покреће подове за које нису постављена ограничења, онда ће за к8с (са становишта потрошње ресурса) то бити еквивалентно као да таквих подова уопште нема на овом чвору. Стога, ако, условно, имате под са прождрљивим процесом (на пример, вовза) и за њега нису постављена никаква ограничења, онда може настати ситуација када овај под заправо поједе све ресурсе чвора, али за к8с овај чвор сматра се неоптерећеним и при рангирању ће му бити додељен исти број поена (тачно у поенима процене расположивих ресурса) као чвор који нема радне подове, што у крајњој линији може довести до неравномерне расподеле оптерећења између чворова.
Исељење Пода
Као што знате, сваком модулу је додељена једна од 3 КоС класе:
- гарантовано — се додељује када су за сваки контејнер у модулу наведени захтев и ограничење за меморију и процесор, а ове вредности морају да се подударају
- бурстабле — бар један контејнер у под има захтев и ограничење, са захтевом < лимит
- најбољи труд — када ниједан контејнер у капсули није ограничен ресурсима
У исто време, када чвор осети недостатак ресурса (диск, меморија), кубелет почиње да рангира и избаци модуле према специфичном алгоритму који узима у обзир приоритет модула и његову КоС класу. На пример, ако говоримо о РАМ-у, онда на основу КоС класе, бодови се додељују по следећем принципу:
- Гарантовано: -998
- БестЕффорт: КСНУМКС
- Бурстабле: мин(мак(2, 1000 - (1000 * мемориРекуестБитес) / мацхинеМемориЦапацитиБитес), 999)
Оне. са истим приоритетом, кубелет ће прво избацити подове са КоС класом најбољег напора из чвора.
Излаз: ако желите да смањите вероватноћу да жељени под буде избачен из чвора у случају недостатка ресурса на њему, онда уз приоритет треба да водите рачуна и о постављању захтева/ограничења за њега.
Механизам за хоризонтално аутоматско скалирање модула апликације (ХПА)
Када је задатак да аутоматски повећава и смањује број подова у зависности од коришћења ресурса (систем - ЦПУ/РАМ или корисник - рпс), као к8с ентитет као нпр. ХПА (Хоризонтал Под Аутосцалер). Алгоритам који је следећи:
- Одређује се тренутна очитавања посматраног ресурса (цуррентМетрицВалуе)
- Одређују се жељене вредности за ресурс (десиредМетрицВалуе), које се за системске ресурсе постављају помоћу захтева
- Одређује се тренутни број реплика (тренутне реплике)
- Следећа формула израчунава жељени број реплика (десиредРеплицас)
жељене реплике = [ тренутне реплике * ( тренутна метричка вредност / жељена вредност метрике )]
У овом случају, до скалирања неће доћи када је коефицијент (цуррентМетрицВалуе / десиредМетрицВалуе) близу 1 (у овом случају можемо сами подесити дозвољену грешку; подразумевано је 0.1).
Погледајмо како хпа функционише на примеру апликације за тестирање апликација (описана као Деплоимент), где је потребно променити број реплика у зависности од потрошње ЦПУ-а:
-
Манифест апликације
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusОне. видимо да се модул апликације иницијално покреће у две инстанце, од којих свака садржи два нгинк и нгинк-екпортер контејнера, за сваки од којих је специфициран Захтеви за ЦПУ.
-
ХПА манифест
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30Оне. Направили смо хпа који ће надгледати тестирање апликације за имплементацију и прилагођавати број подова са апликацијом на основу индикатора процесора (очекујемо да под треба да потроши 30% ЦПУ-а који захтева), са бројем реплика у распон од 2-10.
Сада, погледајмо механизам рада хпа ако применимо оптерећење на једно од огњишта:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Укупно имамо следеће:
- Жељена вредност (десиредМетрицВалуе) - према подешавањима хпа, имамо 30%
- Тренутна вредност (цуррентМетрицВалуе) - за прорачун контролор-менаџер израчунава просечну вредност потрошње ресурса у %, тј. условно ради следеће:
- Прима апсолутне вредности под метрика од метричког сервера, тј. 101м и 4м
- Израчунава просечну апсолутну вредност, тј. (101м + 4м) / 2 = 53м
- Добија апсолутну вредност за жељену потрошњу ресурса (за ово се сумирају захтеви свих контејнера) 60м + 30м = 90м
- Израчунава просечан проценат потрошње ЦПУ-а у односу на модул захтева, тј. 53м / 90м * 100% = 59%
Сада имамо све што нам је потребно да одредимо да ли треба да променимо број реплика; да бисмо то урадили, израчунавамо коефицијент:
ratio = 59% / 30% = 1.96
Оне. број реплика треба повећати за ~2 пута и износити [2 * 1.96] = 4.
Закључак: Као што видите, да би овај механизам функционисао, неопходан услов је присуство захтева за све контејнере у посматраном под-у.
Механизам за хоризонтално аутоматско скалирање чворова (Цлустер Аутосцалер)
Да би се неутралисао негативан утицај на систем током пренапона оптерећења, није довољно имати конфигурисан хпа. На пример, према подешавањима у менаџеру хпа контролера, одлучује да број реплика треба да се повећа за 2 пута, али чворови немају слободне ресурсе за покретање толиког броја подова (тј. чвор не може да обезбеди захтеване ресурсе у модулу са захтевима) и ови подови прелазе у стање на чекању.
У овом случају, ако добављач има одговарајући ИааС/ПааС (на пример, ГКЕ/ГЦЕ, АКС, ЕКС, итд.), алат као што је Ноде Аутосцалер. Омогућава вам да подесите максимални и минимални број чворова у кластеру и аутоматски прилагодите тренутни број чворова (позивањем АПИ добављача облака да наручите/уклоните чвор) када постоји недостатак ресурса у кластеру и подовима не могу се заказати (у стању су на чекању).
Закључак: Да бисте могли да аутоматски скалирате чворове, потребно је поставити захтеве у под контејнерима тако да к8с може исправно проценити оптерећење на чворовима и сходно томе извести да у кластеру нема ресурса за покретање следећег под.
Закључак
Треба напоменути да постављање ограничења ресурса контејнера није услов за успешно покретање апликације, али је ипак боље да то урадите из следећих разлога:
- За прецизнији рад планера у смислу балансирања оптерећења између к8с чворова
- Да би се смањила вероватноћа да дође до „деложације из махуна“.
- За функционисање хоризонталног аутоматског скалирања модула апликације (ХПА).
- За хоризонтално аутоматско скалирање чворова (Цлустер Аутосцалинг) за добављаче облака
Прочитајте и друге чланке на нашем блогу:
Извор: ввв.хабр.цом