AWS પર Kubernetes ક્લાઉડ ખર્ચ પર બચત કરો

લેખનો અનુવાદ કોર્સની શરૂઆતની પૂર્વસંધ્યાએ તૈયાર કરવામાં આવ્યો હતો "કુબરનેટ્સ પર આધારિત ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મ".

કુબરનેટ્સ સાથે કામ કરતી વખતે ક્લાઉડ ખર્ચમાં કેવી રીતે બચત કરવી? ત્યાં કોઈ એક જ યોગ્ય ઉકેલ નથી, પરંતુ આ લેખ ઘણા સાધનોનું વર્ણન કરે છે જે તમને તમારા સંસાધનોને વધુ અસરકારક રીતે સંચાલિત કરવામાં અને તમારા ક્લાઉડ કમ્પ્યુટિંગ ખર્ચને ઘટાડવામાં મદદ કરી શકે છે.

મેં આ લેખ AWS માટે કુબરનેટ્સને ધ્યાનમાં રાખીને લખ્યો છે, પરંતુ તે અન્ય ક્લાઉડ પ્રદાતાઓને (લગભગ) બરાબર એ જ રીતે લાગુ થશે. હું ધારી રહ્યો છું કે તમારા ક્લસ્ટર(ઓ) પહેલાથી જ ઓટોસ્કેલિંગ ગોઠવેલ છે (ક્લસ્ટર-ઓટોસ્કેલર). સંસાધનો દૂર કરવા અને તમારા જમાવટને ઘટાડવાથી તમારા પૈસાની બચત માત્ર ત્યારે જ થશે જો તે તમારા વર્કર નોડ્સ (EC2 દાખલાઓ) ના કાફલાને પણ ઘટાડે છે.

આ લેખ આવરી લેશે:

• ન વપરાયેલ સંસાધનોની સફાઈ (કુબે-દરવાન)
• બિન-કાર્યકારી કલાકો દરમિયાન સ્કેલિંગ ઘટાડો (ક્યુબે-ડાઉનસ્કેલર)
• હોરીઝોન્ટલ ઓટોસ્કેલિંગ (HPA) નો ઉપયોગ કરીને,
• અતિશય સંસાધન આરક્ષણમાં ઘટાડો (kube-સંસાધન-અહેવાલ, VPA)
• સ્પોટ ઉદાહરણોનો ઉપયોગ કરીને

ન વપરાયેલ સંસાધનોની સફાઈ

ઝડપી ગતિશીલ વાતાવરણમાં કામ કરવું એ મહાન છે. અમને ટેક સંસ્થાઓ જોઈએ છે ઝડપી. ઝડપી સૉફ્ટવેર ડિલિવરીનો અર્થ વધુ PR ડિપ્લોયમેન્ટ, પૂર્વાવલોકન વાતાવરણ, પ્રોટોટાઇપ્સ અને એનાલિટિક્સ સોલ્યુશન્સ પણ છે. કુબરનેટ્સ પર બધું જ જમાવવામાં આવ્યું છે. ટેસ્ટ ડિપ્લોયમેન્ટ્સને મેન્યુઅલી સાફ કરવાનો સમય કોની પાસે છે? અઠવાડિયા જૂના પ્રયોગને કાઢી નાખવા વિશે ભૂલી જવું સરળ છે. અમે બંધ કરવાનું ભૂલી ગયા છીએ તેના કારણે ક્લાઉડ બિલ વધશે:

(હેનિંગ જેકોબ્સ:
ઝીઝા:
(અવતરણ) કોરી ક્વિન:
માન્યતા: તમારું AWS એકાઉન્ટ તમારી પાસેના વપરાશકર્તાઓની સંખ્યાનું કાર્ય છે.
હકીકત: તમારો AWS સ્કોર એ તમારી પાસેના એન્જિનિયરોની સંખ્યાનું કાર્ય છે.

ઇવાન કુર્નોસોવ (જવાબમાં):
વાસ્તવિક હકીકત: તમારો AWS સ્કોર એ વસ્તુઓની સંખ્યાનું કાર્ય છે જે તમે અક્ષમ/કાઢી નાખવાનું ભૂલી ગયા છો.)

કુબરનેટસ દરવાન (કુબે-દરવાન) તમારા ક્લસ્ટરને સાફ કરવામાં મદદ કરે છે. દરવાન રૂપરેખાંકન વૈશ્વિક અને સ્થાનિક બંને ઉપયોગ માટે લવચીક છે:

• ક્લસ્ટર-વ્યાપી નિયમો PR/ટેસ્ટ ડિપ્લોયમેન્ટ માટે મહત્તમ સમય-ટુ-લાઇવ (TTL) વ્યાખ્યાયિત કરી શકે છે.
• દરવાન/ttl વડે વ્યક્તિગત સંસાધનોની ટીકા કરી શકાય છે, ઉદાહરણ તરીકે 7 દિવસ પછી સ્પાઇક/પ્રોટોટાઇપને આપમેળે દૂર કરવા માટે.

સામાન્ય નિયમો YAML ફાઇલમાં વ્યાખ્યાયિત થયેલ છે. તેનો માર્ગ પરિમાણમાંથી પસાર થાય છે --rules-file કુબે-દરવાન માં. સાથેની તમામ નેમસ્પેસને દૂર કરવા માટે અહીં એક ઉદાહરણ નિયમ છે -pr- બે દિવસ પછી નામ પર:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

નીચેનું ઉદાહરણ 2020 માં તમામ નવા ડિપ્લોયમેન્ટ/સ્ટેટફુલસેટ્સ માટે ડિપ્લોયમેન્ટ અને સ્ટેટફુલસેટ પોડ્સ પર એપ્લિકેશન લેબલના ઉપયોગને નિયંત્રિત કરે છે, પરંતુ તે જ સમયે એક અઠવાડિયા માટે આ લેબલ વિના પરીક્ષણો ચલાવવાની મંજૂરી આપે છે:

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

કુબે-દરવાન ચાલતા ક્લસ્ટર પર 30 મિનિટ માટે સમય-મર્યાદિત ડેમો ચલાવો:

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

વધતા ખર્ચનો બીજો સ્ત્રોત પર્સિસ્ટન્ટ વોલ્યુમ્સ (AWS EBS) છે. Kubernetes StatefulSet કાઢી નાખવાથી તેના પર્સિસ્ટન્ટ વોલ્યુમ્સ (PVC - PersistentVolumeClaim) ડિલીટ થતા નથી. બિનઉપયોગી EBS વોલ્યુમ સરળતાથી દર મહિને સેંકડો ડોલરના ખર્ચમાં પરિણમી શકે છે. ન વપરાયેલ પીવીસીને સાફ કરવા માટે કુબરનેટસ દરવાન પાસે સુવિધા છે. ઉદાહરણ તરીકે, આ નિયમ તમામ PVC ને દૂર કરશે જે મોડ્યુલ દ્વારા માઉન્ટ થયેલ નથી અને જે સ્ટેટફુલસેટ અથવા ક્રોનજોબ દ્વારા સંદર્ભિત નથી:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor તમને તમારા ક્લસ્ટરને સ્વચ્છ રાખવામાં અને ક્લાઉડ કમ્પ્યુટિંગ ખર્ચને ધીમે ધીમે વધતા અટકાવવામાં મદદ કરી શકે છે. જમાવટ અને રૂપરેખાંકન સૂચનાઓ માટે, અનુસરો README કુબે-દરવાન.

બિન-કાર્યકારી કલાકો દરમિયાન સ્કેલિંગ ઘટાડો

ટેસ્ટ અને સ્ટેજીંગ સિસ્ટમો સામાન્ય રીતે કામકાજના કલાકો દરમિયાન જ ઓપરેશન માટે જરૂરી છે. કેટલીક પ્રોડક્શન એપ્લિકેશન્સ, જેમ કે બેક ઓફિસ/એડમિન ટૂલ્સને પણ માત્ર મર્યાદિત ઉપલબ્ધતાની જરૂર હોય છે અને તે રાતોરાત અક્ષમ થઈ શકે છે.

કુબરનેટ્સ ડાઉનસ્કેલર (kube-downscaler) વપરાશકર્તાઓ અને ઓપરેટરોને બિન-કાર્યકારી કલાકો દરમિયાન સિસ્ટમને માપવા માટે પરવાનગી આપે છે. ડિપ્લોયમેન્ટ્સ અને સ્ટેટફુલસેટ્સ શૂન્ય પ્રતિકૃતિઓ સુધી સ્કેલ કરી શકે છે. CronJobs સસ્પેન્ડ થઈ શકે છે. Kubernetes Downscaler સમગ્ર ક્લસ્ટર, એક અથવા વધુ નેમસ્પેસ અથવા વ્યક્તિગત સંસાધનો માટે ગોઠવેલ છે. તમે ક્યાં તો "નિષ્ક્રિય સમય" અથવા તેનાથી વિપરીત, "કામનો સમય" સેટ કરી શકો છો. ઉદાહરણ તરીકે, રાત્રિ અને સપ્તાહના અંતે શક્ય તેટલું સ્કેલિંગ ઘટાડવા માટે:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

અહીં સપ્તાહના અંતે ક્લસ્ટર વર્કર નોડ્સને માપવા માટેનો ગ્રાફ છે:

~13 થી 4 વર્કર નોડ્સને ઘટાડવાથી તમારા AWS બિલમાં ચોક્કસપણે નોંધપાત્ર તફાવત આવે છે.

પરંતુ જો મારે ક્લસ્ટર "ડાઉનટાઇમ" દરમિયાન કામ કરવાની જરૂર હોય તો શું? અમુક જમાવટને ડાઉનસ્કેલર/બાકાત: સાચી ટીકા ઉમેરીને સ્કેલિંગમાંથી કાયમ માટે બાકાત કરી શકાય છે. YYYY-MM-DD HH:MM (UTC). જો જરૂરી હોય તો, એનોટેશન સાથે પોડ ગોઠવીને સમગ્ર ક્લસ્ટરને પાછું માપી શકાય છે downscaler/force-uptime, ઉદાહરણ તરીકે, nginx ખાલી લોન્ચ કરીને:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

જુઓ README ક્યુબ-ડાઉનસ્કેલર, જો તમે જમાવટ સૂચનાઓ અને વધારાના વિકલ્પોમાં રસ ધરાવો છો.

આડી ઓટોસ્કેલિંગનો ઉપયોગ કરો

ઘણી એપ્લિકેશન્સ/સેવાઓ ગતિશીલ લોડિંગ પેટર્ન સાથે વ્યવહાર કરે છે: કેટલીકવાર તેમના મોડ્યુલો નિષ્ક્રિય હોય છે, અને કેટલીકવાર તેઓ સંપૂર્ણ ક્ષમતા પર કાર્ય કરે છે. મહત્તમ પીક લોડનો સામનો કરવા માટે પોડ્સના કાયમી કાફલાનું સંચાલન કરવું આર્થિક નથી. Kubernetes સમગ્ર સંસાધનમાં આડી ઓટો-સ્કેલિંગને સપોર્ટ કરે છે હોરિઝોન્ટલ પોડ ઓટોસ્કેલર (HPA). CPU નો ઉપયોગ ઘણીવાર સ્કેલિંગ માટે સારો સૂચક છે:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando એ સ્કેલિંગ માટે કસ્ટમ મેટ્રિક્સને સરળતાથી કનેક્ટ કરવા માટે એક ઘટક બનાવ્યું છે: કુબે મેટ્રિક્સ એડેપ્ટર (kube-metrics-adapter) કુબરનેટ્સ માટે એક સામાન્ય મેટ્રિક્સ એડેપ્ટર છે જે પોડ્સના આડા ઓટોસ્કેલિંગ માટે કસ્ટમ અને બાહ્ય મેટ્રિક્સ એકત્રિત કરી શકે છે અને સેવા આપી શકે છે. તે પ્રોમિથિયસ મેટ્રિક્સ, SQS કતાર અને અન્ય સેટિંગ્સ પર આધારિત સ્કેલિંગને સપોર્ટ કરે છે. ઉદાહરણ તરીકે, તમારી ડિપ્લોયમેન્ટને કસ્ટમ મેટ્રિક પર સ્કેલ કરવા માટે જે એપ્લીકેશન દ્વારા જ /મેટ્રિક્સના ઉપયોગમાં JSON તરીકે રજૂ કરવામાં આવે છે:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

સ્ટેટલેસ સેવાઓ માટે કાર્યક્ષમતા સુધારવા માટે એચપીએ સાથે આડી ઓટોસ્કેલિંગને ગોઠવવી એ ડિફોલ્ટ ક્રિયાઓમાંની એક હોવી જોઈએ. Spotify પાસે તેમના અનુભવ અને HPA માટેની ભલામણો સાથે પ્રસ્તુતિ છે: તમારી જમાવટને માપો, તમારા વૉલેટને નહીં.

સંસાધન ઓવરબુકિંગ ઘટાડો

કુબરનેટ્સ વર્કલોડ "સંસાધન વિનંતીઓ" દ્વારા તેમની CPU/મેમરી જરૂરિયાતો નક્કી કરે છે. CPU સંસાધનો વર્ચ્યુઅલ કોરોમાં અથવા વધુ સામાન્ય રીતે "મિલીકોર" માં માપવામાં આવે છે, ઉદાહરણ તરીકે 500m 50% vCPU સૂચવે છે. મેમરી સંસાધનો બાઇટ્સમાં માપવામાં આવે છે, અને સામાન્ય પ્રત્યયનો ઉપયોગ કરી શકાય છે, જેમ કે 500Mi, જેનો અર્થ થાય છે 500 મેગાબાઇટ્સ. સંસાધન વિનંતીઓ વર્કર નોડ્સ પર "લોક" ક્ષમતા ધરાવે છે, એટલે કે 1000 vCPU સાથે નોડ પર 4m CPU વિનંતી સાથેનો પોડ અન્ય પોડ્સ માટે માત્ર 3 vCPUs ઉપલબ્ધ રહેશે. [1]

સ્લેક (વધારે અનામત) વિનંતી કરેલ સંસાધનો અને વાસ્તવિક ઉપયોગ વચ્ચેનો તફાવત છે. ઉદાહરણ તરીકે, પોડ કે જે 2 GiB મેમરીની વિનંતી કરે છે પરંતુ માત્ર 200 MiB વાપરે છે તેમાં ~1,8 GiB "વધારાની" મેમરી હોય છે. વધુ પડતા પૈસા ખર્ચ થાય છે. કોઈ અંદાજે અંદાજ લગાવી શકે છે કે 1 GiB રીડન્ડન્ટ મેમરીનો ખર્ચ દર મહિને ~$10 છે. [2]

કુબરનેટ્સ રિસોર્સ રિપોર્ટ (kube-resource-report) અધિક અનામત પ્રદર્શિત કરે છે અને તમને બચતની સંભાવના નક્કી કરવામાં મદદ કરી શકે છે:

કુબરનેટ્સ રિસોર્સ રિપોર્ટ એપ્લીકેશન અને કમાન્ડ દ્વારા એકત્ર કરેલ વધારાને દર્શાવે છે. આ તમને એવા સ્થાનો શોધવાની મંજૂરી આપે છે જ્યાં સંસાધનની માંગ ઘટાડી શકાય છે. જનરેટ કરેલ HTML રિપોર્ટ માત્ર સંસાધન વપરાશનો સ્નેપશોટ પૂરો પાડે છે. પર્યાપ્ત સંસાધન વિનંતીઓ નક્કી કરવા માટે તમારે સમય જતાં CPU/મેમરીનો ઉપયોગ જોવો જોઈએ. "સામાન્ય" CPU-ભારે સેવા માટે અહીં એક Grafana ચાર્ટ છે: બધા પોડ્સ વિનંતી કરેલ 3 CPU કોરો કરતાં નોંધપાત્ર રીતે ઓછા ઉપયોગ કરી રહ્યાં છે:

CPU વિનંતીને 3000m થી ~400m સુધી ઘટાડવાથી અન્ય વર્કલોડ માટે સંસાધનો મુક્ત થાય છે અને ક્લસ્ટરને નાનું થવા દે છે.

"EC2 ઉદાહરણોનો સરેરાશ CPU ઉપયોગ ઘણીવાર સિંગલ-ડિજિટ ટકાવારીની શ્રેણીમાં રહે છે," કોરી ક્વિન લખે છે. જ્યારે EC2 માટે યોગ્ય કદનો અંદાજ કાઢવો એ ખરાબ નિર્ણય હોઈ શકે છેYAML ફાઇલમાં કુબરનેટ્સ રિસોર્સ ક્વેરીઝ બદલવાનું સરળ છે અને મોટી બચત લાવી શકે છે.

પરંતુ શું આપણે ખરેખર ઇચ્છીએ છીએ કે લોકો YAML ફાઇલોમાં મૂલ્યો બદલે? ના, મશીનો તે વધુ સારી રીતે કરી શકે છે! કુબરનેટ્સ વર્ટિકલ પોડ ઓટોસ્કેલર (VPA) તે જ કરે છે: વર્કલોડ અનુસાર સંસાધન વિનંતીઓ અને અવરોધોને અપનાવે છે. VPA દ્વારા સમયાંતરે અનુકૂલિત પ્રોમિથિયસ CPU વિનંતીઓ (પાતળી વાદળી રેખા) નો એક ઉદાહરણ આલેખ છે:

Zalando તેના તમામ ક્લસ્ટરોમાં VPA નો ઉપયોગ કરે છે ઇન્ફ્રાસ્ટ્રક્ચર ઘટકો માટે. બિન-નિર્ણાયક એપ્લિકેશનો પણ VPA નો ઉપયોગ કરી શકે છે.

ગોલ્ડિલocksક્સ ફ્રોમ ફેરવિન્ડ એ એક સાધન છે જે નેમસ્પેસમાં દરેક જમાવટ માટે VPA બનાવે છે અને પછી તેના ડેશબોર્ડ પર VPA ભલામણ પ્રદર્શિત કરે છે. તે વિકાસકર્તાઓને તેમની એપ્લિકેશનો માટે યોગ્ય CPU/મેમરી વિનંતીઓ સેટ કરવામાં મદદ કરી શકે છે:

મેં એક નાનું લખ્યું VPA વિશે બ્લોગપોસ્ટ 2019 માં, અને તાજેતરમાં માં CNCF અંતિમ વપરાશકર્તા સમુદાયે VPA મુદ્દાની ચર્ચા કરી.

EC2 સ્પોટ ઇન્સ્ટન્સનો ઉપયોગ કરીને

છેલ્લું પરંતુ ઓછામાં ઓછું નહીં, AWS EC2 ખર્ચને કુબરનેટ્સ વર્કર નોડ્સ તરીકે સ્પોટ ઇન્સ્ટન્સનો ઉપયોગ કરીને ઘટાડી શકાય છે. [3]. ઑન-ડિમાન્ડ કિંમતોની સરખામણીમાં 90% સુધીના ડિસ્કાઉન્ટ પર સ્પોટ ઇન્સ્ટન્સ ઉપલબ્ધ છે. EC2 સ્પોટ પર કુબરનેટ્સ ચલાવવું એ એક સારું સંયોજન છે: તમારે ઉચ્ચ ઉપલબ્ધતા માટે ઘણા જુદા જુદા દાખલા પ્રકારોનો ઉલ્લેખ કરવાની જરૂર છે, એટલે કે તમે સમાન અથવા ઓછી કિંમતે મોટો નોડ મેળવી શકો છો, અને વધેલી ક્ષમતાનો ઉપયોગ કન્ટેનરાઇઝ્ડ કુબરનેટ્સ વર્કલોડ દ્વારા કરી શકાય છે.

EC2 સ્પોટ પર કુબરનેટ્સ કેવી રીતે ચલાવવું? ત્યાં ઘણા બધા વિકલ્પો છે: SpotInst જેવી તૃતીય પક્ષ સેવાનો ઉપયોગ કરો (હવે "સ્પોટ" કહેવાય છે, મને કેમ પૂછશો નહીં), અથવા ફક્ત તમારા ક્લસ્ટરમાં Spot AutoScalingGroup (ASG) ઉમેરો. ઉદાહરણ તરીકે, બહુવિધ ઇન્સ્ટન્સ પ્રકારો સાથે "ક્ષમતા-ઓપ્ટિમાઇઝ" સ્પોટ ASG માટે અહીં ક્લાઉડફોર્મેશન સ્નિપેટ છે:

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

કુબરનેટ્સ સાથે સ્પોટનો ઉપયોગ કરવા માટેની કેટલીક નોંધો:

• તમારે સ્પોટ ટર્મિનેશનને હેન્ડલ કરવાની જરૂર છે, ઉદાહરણ તરીકે જ્યારે ઇન્સ્ટન્સ બંધ થાય ત્યારે નોડને મર્જ કરીને
• Zalando ઉપયોગ કરે છે કાંટો નોડ પૂલ પ્રાથમિકતાઓ સાથે સત્તાવાર ક્લસ્ટર ઓટોસ્કેલિંગ
• સ્પોટ નોડ્સ દબાણ કરી શકાય છે સ્પોટમાં ચલાવવા માટે વર્કલોડની "નોંધણી" સ્વીકારો

સારાંશ

હું આશા રાખું છું કે તમને તમારા ક્લાઉડ બિલને ઘટાડવામાં પ્રસ્તુત કેટલાક સાધનો ઉપયોગી લાગશે. તમે લેખની મોટાભાગની સામગ્રીઓ અહીં પણ મેળવી શકો છો યુટ્યુબ પર અને સ્લાઇડ્સમાં DevOps ગેધરીંગ 2019 પર મારી ચર્ચા.

કુબરનેટ્સ પર ક્લાઉડ ખર્ચ બચાવવા માટે તમારી શ્રેષ્ઠ પદ્ધતિઓ શું છે? કૃપા કરીને મને જણાવો Twitter (@try_except_).

[1] વાસ્તવમાં, આરક્ષિત સિસ્ટમ સંસાધનો દ્વારા નોડના થ્રુપુટમાં ઘટાડો થવાને કારણે 3 કરતાં ઓછા vCPUs ઉપયોગી રહેશે. કુબરનેટ્સ ભૌતિક નોડ ક્ષમતા અને "જોગવાઈ કરેલ" સંસાધનો વચ્ચે તફાવત કરે છે (નોડ ફાળવણીયોગ્ય).

[2] ગણતરીનું ઉદાહરણ: 5 GiB મેમરી સાથેનો એક m8.મોટો દાખલો દર મહિને ~$84 ​​છે (eu-central-1, On-Demand), એટલે કે. 1/8 નોડને અવરોધિત કરવાનું આશરે ~$10/મહિને છે.

[3] તમારા EC2 બિલને ઘટાડવાની ઘણી વધુ રીતો છે, જેમ કે આરક્ષિત દાખલાઓ, બચત યોજના, વગેરે. - હું તે વિષયોને અહીં કવર કરીશ નહીં, પરંતુ તમારે ચોક્કસપણે તેમને જોવું જોઈએ!

કોર્સ વિશે વધુ જાણો.

સોર્સ: www.habr.com