AWS 'ਤੇ ਕੁਬਰਨੇਟਸ ਕਲਾਉਡ ਖਰਚਿਆਂ 'ਤੇ ਬਚਤ ਕਰੋ

ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੋਰਸ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਪੂਰਵ ਸੰਧਿਆ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ "ਕੁਬਰਨੇਟਸ 'ਤੇ ਅਧਾਰਤ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪਲੇਟਫਾਰਮ".

ਕੁਬਰਨੇਟਸ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਕਲਾਉਡ ਖਰਚਿਆਂ ਨੂੰ ਕਿਵੇਂ ਬਚਾਇਆ ਜਾਵੇ? ਇੱਥੇ ਕੋਈ ਵੀ ਸਹੀ ਹੱਲ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਲੇਖ ਕਈ ਸਾਧਨਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਰੋਤਾਂ ਨੂੰ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਨ ਕਰਨ ਅਤੇ ਤੁਹਾਡੇ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਖਰਚਿਆਂ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।

ਮੈਂ ਇਹ ਲੇਖ AWS ਲਈ Kubernetes ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਲਿਖਿਆ ਸੀ, ਪਰ ਇਹ ਦੂਜੇ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ (ਲਗਭਗ) ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਹੋਵੇਗਾ। ਮੈਂ ਇਹ ਮੰਨ ਰਿਹਾ/ਰਹੀ ਹਾਂ ਕਿ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਪਹਿਲਾਂ ਹੀ ਆਟੋਸਕੇਲਿੰਗ ਕੌਂਫਿਗਰ ਕੀਤੇ ਹੋਏ ਹਨ (ਕਲੱਸਟਰ-ਆਟੋਸਕੇਲਰ). ਸਰੋਤਾਂ ਨੂੰ ਹਟਾਉਣਾ ਅਤੇ ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਨੂੰ ਘਟਾਉਣਾ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਪੈਸੇ ਦੀ ਬਚਤ ਕਰੇਗਾ ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਵਰਕਰ ਨੋਡਜ਼ (EC2 ਉਦਾਹਰਨਾਂ) ਦੇ ਫਲੀਟ ਨੂੰ ਵੀ ਘਟਾਉਂਦਾ ਹੈ।

ਇਹ ਲੇਖ ਕਵਰ ਕਰੇਗਾ:

• ਨਾ ਵਰਤੇ ਸਰੋਤਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ (ਕੁਬੇ-ਦਰਬਾਰ)
• ਗੈਰ-ਕੰਮ ਦੇ ਘੰਟਿਆਂ ਦੌਰਾਨ ਸਕੇਲਿੰਗ ਘਟਾਓ (kube-downscaler)
• ਹਰੀਜੋਂਟਲ ਆਟੋਸਕੇਲਿੰਗ (HPA) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ,
• ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਰੋਤ ਰਿਜ਼ਰਵੇਸ਼ਨ ਦੀ ਕਮੀ (kube-resource-report, VPA)
• ਸਪੌਟ ਉਦਾਹਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ

ਨਾ ਵਰਤੇ ਸਰੋਤਾਂ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ

ਇੱਕ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਵਾਲੇ ਮਾਹੌਲ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਬਹੁਤ ਵਧੀਆ ਹੈ. ਅਸੀਂ ਤਕਨੀਕੀ ਸੰਸਥਾਵਾਂ ਚਾਹੁੰਦੇ ਹਾਂ ਤੇਜ਼ ਕੀਤਾ. ਤੇਜ਼ ਸੌਫਟਵੇਅਰ ਡਿਲੀਵਰੀ ਦਾ ਮਤਲਬ ਹੋਰ PR ਤੈਨਾਤੀਆਂ, ਪੂਰਵਦਰਸ਼ਨ ਵਾਤਾਵਰਣ, ਪ੍ਰੋਟੋਟਾਈਪ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਹੱਲ ਵੀ ਹੈ। ਕੁਬਰਨੇਟਸ 'ਤੇ ਸਭ ਕੁਝ ਤੈਨਾਤ ਹੈ। ਕਿਸ ਕੋਲ ਟੈਸਟ ਤੈਨਾਤੀਆਂ ਨੂੰ ਹੱਥੀਂ ਸਾਫ਼ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ? ਇੱਕ ਹਫ਼ਤੇ ਪੁਰਾਣੇ ਪ੍ਰਯੋਗ ਨੂੰ ਮਿਟਾਉਣ ਬਾਰੇ ਭੁੱਲਣਾ ਆਸਾਨ ਹੈ। ਕਲਾਉਡ ਬਿੱਲ ਉਸ ਚੀਜ਼ ਦੇ ਕਾਰਨ ਵੱਧ ਜਾਵੇਗਾ ਜਿਸ ਨੂੰ ਅਸੀਂ ਬੰਦ ਕਰਨਾ ਭੁੱਲ ਗਏ ਹਾਂ:

(ਹੇਨਿੰਗ ਜੈਕਬਸ:
Zhiza:
(ਹਵਾਲੇ) ਕੋਰੀ ਕੁਇਨ:
ਮਿੱਥ: ਤੁਹਾਡਾ AWS ਖਾਤਾ ਤੁਹਾਡੇ ਕੋਲ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੰਖਿਆ ਦਾ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ।
ਤੱਥ: ਤੁਹਾਡਾ AWS ਸਕੋਰ ਤੁਹਾਡੇ ਕੋਲ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਸੰਖਿਆ ਦਾ ਇੱਕ ਕਾਰਜ ਹੈ।

ਇਵਾਨ ਕੁਰਨੋਸੋਵ (ਜਵਾਬ ਵਿੱਚ):
ਅਸਲ ਤੱਥ: ਤੁਹਾਡਾ AWS ਸਕੋਰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਦੀ ਸੰਖਿਆ ਦਾ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਤੁਸੀਂ ਅਯੋਗ/ਮਿਟਾਉਣਾ ਭੁੱਲ ਗਏ ਹੋ।)

ਕੁਬਰਨੇਟਸ ਜੈਨੀਟਰ (kube- janitor) ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਦਰਬਾਨ ਸੰਰਚਨਾ ਗਲੋਬਲ ਅਤੇ ਸਥਾਨਕ ਵਰਤੋਂ ਲਈ ਲਚਕਦਾਰ ਹੈ:

• ਕਲੱਸਟਰ-ਵਿਆਪਕ ਨਿਯਮ PR/ਟੈਸਟ ਤੈਨਾਤੀਆਂ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਟਾਈਮ-ਟੂ-ਲਾਈਵ (TTL) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ।
• ਵਿਅਕਤੀਗਤ ਸਰੋਤਾਂ ਨੂੰ janitor/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) ਹੈ। ਕੁਬਰਨੇਟਸ ਸਟੇਟਫੁਲਸੈਟ ਨੂੰ ਮਿਟਾਉਣ ਨਾਲ ਇਸ ਦੇ ਨਿਰੰਤਰ ਵੌਲਯੂਮ (ਪੀਵੀਸੀ - ਪਰਸਿਸਟੈਂਟਵੋਲਯੂਮ ਕਲੇਮ) ਨਹੀਂ ਮਿਟਦੇ ਹਨ। ਅਣਵਰਤੇ EBS ਵਾਲੀਅਮ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਤੀ ਮਹੀਨਾ ਸੈਂਕੜੇ ਡਾਲਰ ਦੀ ਲਾਗਤ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੋ ਸਕਦੇ ਹਨ। ਕੁਬਰਨੇਟਸ ਜੈਨੀਟਰ ਕੋਲ ਨਾ ਵਰਤੇ ਗਏ ਪੀਵੀਸੀ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਨਿਯਮ ਉਹਨਾਂ ਸਾਰੇ PVCs ਨੂੰ ਹਟਾ ਦੇਵੇਗਾ ਜੋ ਇੱਕ ਮੋਡੀਊਲ ਦੁਆਰਾ ਮਾਊਂਟ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਜਿਹਨਾਂ ਦਾ ਇੱਕ ਸਟੇਟਫੁਲਸੈੱਟ ਜਾਂ ਕ੍ਰੋਨਜੌਬ ਦੁਆਰਾ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਹੈ:

# удалить все 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 ਕਿਊਬ-ਡਾਊਨਸਕੇਲਰ, ਜੇਕਰ ਤੁਸੀਂ ਤੈਨਾਤੀ ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਵਾਧੂ ਵਿਕਲਪਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ।

ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ/ਸੇਵਾਵਾਂ ਇੱਕ ਗਤੀਸ਼ੀਲ ਲੋਡਿੰਗ ਪੈਟਰਨ ਨਾਲ ਨਜਿੱਠਦੀਆਂ ਹਨ: ਕਈ ਵਾਰ ਉਹਨਾਂ ਦੇ ਮੋਡੀਊਲ ਵਿਹਲੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰ ਉਹ ਪੂਰੀ ਸਮਰੱਥਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਵੱਧ ਤੋਂ ਵੱਧ ਪੀਕ ਲੋਡ ਨਾਲ ਸਿੱਝਣ ਲਈ ਪੌਡਾਂ ਦੇ ਸਥਾਈ ਫਲੀਟ ਨੂੰ ਚਲਾਉਣਾ ਕਿਫ਼ਾਇਤੀ ਨਹੀਂ ਹੈ। ਕੁਬਰਨੇਟਸ ਇੱਕ ਸਰੋਤ ਵਿੱਚ ਹਰੀਜੱਟਲ ਆਟੋ-ਸਕੇਲਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ HorizontalPodAutoscaler (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

ਜ਼ਲੈਂਡੋ ਨੇ ਸਕੇਲਿੰਗ ਲਈ ਕਸਟਮ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਜੋੜਨ ਲਈ ਇੱਕ ਭਾਗ ਬਣਾਇਆ ਹੈ: ਕੁਬੇ ਮੈਟ੍ਰਿਕਸ ਅਡਾਪਟਰ (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

HPA ਨਾਲ ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨਾ ਸਟੇਟਲੈੱਸ ਸੇਵਾਵਾਂ ਲਈ ਕੁਸ਼ਲਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਡਿਫੌਲਟ ਕਾਰਵਾਈਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Spotify ਕੋਲ ਉਹਨਾਂ ਦੇ ਤਜ਼ਰਬੇ ਅਤੇ HPA ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦੇ ਨਾਲ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਹੈ: ਤੁਹਾਡੀਆਂ ਤੈਨਾਤੀਆਂ ਨੂੰ ਸਕੇਲ ਕਰੋ, ਤੁਹਾਡੇ ਬਟੂਏ ਨੂੰ ਨਹੀਂ.

ਸਰੋਤ ਓਵਰਬੁਕਿੰਗ ਨੂੰ ਘਟਾਓ

ਕੁਬਰਨੇਟਸ ਵਰਕਲੋਡ "ਸਰੋਤ ਬੇਨਤੀਆਂ" ਦੁਆਰਾ ਉਹਨਾਂ ਦੀਆਂ CPU/ਮੈਮੋਰੀ ਲੋੜਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। CPU ਸਰੋਤਾਂ ਨੂੰ ਵਰਚੁਅਲ ਕੋਰ ਵਿੱਚ ਜਾਂ ਆਮ ਤੌਰ 'ਤੇ "ਮਿਲੀਕੋਰਸ" ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ 500m ਦਾ ਮਤਲਬ 50% vCPU ਹੈ। ਮੈਮੋਰੀ ਸਰੋਤਾਂ ਨੂੰ ਬਾਈਟਾਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਆਮ ਪਿਛੇਤਰ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ 500Mi, ਜਿਸਦਾ ਮਤਲਬ ਹੈ 500 ਮੈਗਾਬਾਈਟ। ਸਰੋਤ ਬੇਨਤੀਆਂ ਵਰਕਰ ਨੋਡਾਂ 'ਤੇ "ਲਾਕ" ਸਮਰੱਥਾ, ਭਾਵ 1000 vCPUs ਵਾਲੇ ਨੋਡ 'ਤੇ 4m CPU ਬੇਨਤੀ ਵਾਲਾ ਇੱਕ ਪੌਡ ਹੋਰ ਪੌਡਾਂ ਲਈ ਸਿਰਫ਼ 3 vCPUs ਨੂੰ ਹੀ ਛੱਡ ਦੇਵੇਗਾ। [1]

ਢਿੱਲ (ਵਾਧੂ ਰਿਜ਼ਰਵ) ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ ਅਤੇ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਅੰਤਰ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਪੌਡ ਜੋ 2 GiB ਮੈਮੋਰੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਪਰ ਸਿਰਫ਼ 200 MiB ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਵਿੱਚ ~ 1,8 GiB "ਵੱਧ" ਮੈਮੋਰੀ ਹੁੰਦੀ ਹੈ। ਵਾਧੂ ਪੈਸੇ ਖਰਚਦੇ ਹਨ। ਕੋਈ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦਾ ਹੈ ਕਿ 1 GiB ਬੇਲੋੜੀ ਮੈਮੋਰੀ ਪ੍ਰਤੀ ਮਹੀਨਾ ~ $10 ਖਰਚ ਕਰਦੀ ਹੈ। [2]

Kubernetes ਸਰੋਤ ਰਿਪੋਰਟ (kube-resource-report) ਵਾਧੂ ਭੰਡਾਰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਬਚਤ ਦੀ ਸੰਭਾਵਨਾ ਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:

Kubernetes ਸਰੋਤ ਰਿਪੋਰਟ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਕਮਾਂਡ ਦੁਆਰਾ ਇਕੱਠੇ ਕੀਤੇ ਵਾਧੂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਸਥਾਨਾਂ ਨੂੰ ਲੱਭਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਸਰੋਤਾਂ ਦੀ ਮੰਗ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਤਿਆਰ ਕੀਤੀ HTML ਰਿਪੋਰਟ ਕੇਵਲ ਸਰੋਤ ਵਰਤੋਂ ਦਾ ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਸਰੋਤ ਬੇਨਤੀਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਸਮੇਂ ਦੇ ਨਾਲ CPU/ਮੈਮੋਰੀ ਵਰਤੋਂ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਇੱਕ "ਆਮ" CPU-ਭਾਰੀ ਸੇਵਾ ਲਈ ਇੱਕ Grafana ਚਾਰਟ ਹੈ: ਸਾਰੇ ਪੌਡ 3 ਬੇਨਤੀ ਕੀਤੇ CPU ਕੋਰਾਂ ਤੋਂ ਕਾਫ਼ੀ ਘੱਟ ਵਰਤ ਰਹੇ ਹਨ:

CPU ਬੇਨਤੀ ਨੂੰ 3000m ਤੋਂ ~400m ਤੱਕ ਘਟਾਉਣਾ ਹੋਰ ਵਰਕਲੋਡਾਂ ਲਈ ਸਰੋਤਾਂ ਨੂੰ ਖਾਲੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰ ਨੂੰ ਛੋਟਾ ਹੋਣ ਦਿੰਦਾ ਹੈ।

"EC2 ਮੌਕਿਆਂ ਦੀ ਔਸਤ CPU ਵਰਤੋਂ ਅਕਸਰ ਸਿੰਗਲ-ਅੰਕ ਪ੍ਰਤੀਸ਼ਤ ਸੀਮਾ ਵਿੱਚ ਘੁੰਮਦੀ ਹੈ," ਕੋਰੀ ਕੁਇਨ ਲਿਖਦਾ ਹੈ. ਜਦੋਂ ਕਿ EC2 ਲਈ ਸਹੀ ਆਕਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਇੱਕ ਬੁਰਾ ਫੈਸਲਾ ਹੋ ਸਕਦਾ ਹੈYAML ਫਾਈਲ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਸਰੋਤ ਸਵਾਲਾਂ ਨੂੰ ਬਦਲਣਾ ਆਸਾਨ ਹੈ ਅਤੇ ਵੱਡੀ ਬੱਚਤ ਲਿਆ ਸਕਦਾ ਹੈ।

ਪਰ ਕੀ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਲੋਕ YAML ਫਾਈਲਾਂ ਵਿੱਚ ਮੁੱਲ ਬਦਲ ਰਹੇ ਹਨ? ਨਹੀਂ, ਮਸ਼ੀਨਾਂ ਇਹ ਬਹੁਤ ਵਧੀਆ ਕਰ ਸਕਦੀਆਂ ਹਨ! ਕੁਬਰਨੇਟਸ ਵਰਟੀਕਲ ਪੋਡ ਆਟੋਸਕੇਲਰ (VPA) ਇਹੀ ਕਰਦਾ ਹੈ: ਕੰਮ ਦੇ ਬੋਝ ਦੇ ਅਨੁਸਾਰ ਸਰੋਤ ਬੇਨਤੀਆਂ ਅਤੇ ਰੁਕਾਵਟਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ। VPA ਦੁਆਰਾ ਸਮੇਂ ਦੇ ਨਾਲ ਅਨੁਕੂਲਿਤ ਪ੍ਰੋਮੀਥੀਅਸ CPU ਬੇਨਤੀਆਂ (ਪਤਲੀ ਨੀਲੀ ਲਾਈਨ) ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਗ੍ਰਾਫ਼ ਇੱਥੇ ਹੈ:

ਜ਼ਲੈਂਡੋ ਆਪਣੇ ਸਾਰੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ VPA ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਲਈ. ਗੈਰ-ਨਾਜ਼ੁਕ ਐਪਲੀਕੇਸ਼ਨ ਵੀ VPA ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ।

ਗੋਲਡਿਲਕਸ ਫੇਅਰਵਿੰਡ ਤੋਂ ਇੱਕ ਟੂਲ ਹੈ ਜੋ ਇੱਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਹਰੇਕ ਤੈਨਾਤੀ ਲਈ ਇੱਕ VPA ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇਸਦੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਇੱਕ VPA ਸਿਫ਼ਾਰਿਸ਼ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਹੀ CPU/ਮੈਮੋਰੀ ਬੇਨਤੀਆਂ ਸੈਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:

ਮੈਂ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਲਿਖਿਆ VPA ਬਾਰੇ ਬਲੌਗਪੋਸਟ 2019 ਵਿੱਚ, ਅਤੇ ਹਾਲ ਹੀ ਵਿੱਚ CNCF ਅੰਤਮ ਉਪਭੋਗਤਾ ਭਾਈਚਾਰੇ ਨੇ VPA ਮੁੱਦੇ 'ਤੇ ਚਰਚਾ ਕੀਤੀ.

EC2 ਸਪਾਟ ਉਦਾਹਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਆਖਰੀ ਪਰ ਘੱਟੋ-ਘੱਟ ਨਹੀਂ, ਕੁਬਰਨੇਟਸ ਵਰਕਰ ਨੋਡਸ ਦੇ ਤੌਰ 'ਤੇ ਸਪੌਟ ਉਦਾਹਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ AWS EC2 ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। [3]. ਆਨ-ਡਿਮਾਂਡ ਕੀਮਤਾਂ ਦੇ ਮੁਕਾਬਲੇ ਸਪਾਟ ਉਦਾਹਰਨਾਂ 90% ਤੱਕ ਦੀ ਛੋਟ 'ਤੇ ਉਪਲਬਧ ਹਨ। EC2 ਸਪਾਟ 'ਤੇ ਕੁਬਰਨੇਟਸ ਚਲਾਉਣਾ ਇੱਕ ਚੰਗਾ ਸੁਮੇਲ ਹੈ: ਤੁਹਾਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ ਲਈ ਕਈ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਮਤਲਬ ਕਿ ਤੁਸੀਂ ਉਸੇ ਜਾਂ ਘੱਟ ਕੀਮਤ ਲਈ ਇੱਕ ਵੱਡਾ ਨੋਡ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਵਧੀ ਹੋਈ ਸਮਰੱਥਾ ਨੂੰ ਕੰਟੇਨਰਾਈਜ਼ਡ ਕੁਬਰਨੇਟਸ ਵਰਕਲੋਡ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

EC2 ਸਪਾਟ 'ਤੇ ਕੁਬਰਨੇਟਸ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ? ਇੱਥੇ ਕਈ ਵਿਕਲਪ ਹਨ: ਇੱਕ ਤੀਜੀ ਧਿਰ ਦੀ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਵੇਂ ਕਿ SpotInst (ਹੁਣ "Spot" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਮੈਨੂੰ ਕਿਉਂ ਨਾ ਪੁੱਛੋ), ਜਾਂ ਬਸ ਆਪਣੇ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ Spot AutoScalingGroup (ASG) ਸ਼ਾਮਲ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਇੱਕ "ਸਮਰੱਥਾ-ਅਨੁਕੂਲਿਤ" ਸਪਾਟ ASG ਲਈ ਇੱਕ CloudFormation ਸਨਿੱਪਟ ਹੈ ਜਿਸ ਵਿੱਚ ਮਲਟੀਪਲ ਉਦਾਹਰਨ ਕਿਸਮਾਂ ਹਨ:

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"

ਕੁਬਰਨੇਟਸ ਨਾਲ ਸਪਾਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਕੁਝ ਨੋਟ:

• ਤੁਹਾਨੂੰ ਸਪਾਟ ਸਮਾਪਤੀ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਨੋਡ ਨੂੰ ਮਿਲਾ ਕੇ ਜਦੋਂ ਉਦਾਹਰਨ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ
• ਜ਼ਲੈਂਡੋ ਵਰਤਦਾ ਹੈ ਕਾਂਟਾ ਨੋਡ ਪੂਲ ਤਰਜੀਹਾਂ ਦੇ ਨਾਲ ਅਧਿਕਾਰਤ ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਿੰਗ
• ਸਪਾਟ ਨੋਡਸ ਮਜਬੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਸਪਾਟ ਵਿੱਚ ਚੱਲਣ ਲਈ ਵਰਕਲੋਡ ਦੀਆਂ "ਰਜਿਸਟ੍ਰੇਸ਼ਨਾਂ" ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ

ਸੰਖੇਪ

ਮੈਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਕਲਾਉਡ ਬਿੱਲ ਨੂੰ ਘਟਾਉਣ ਲਈ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਕੁਝ ਸਾਧਨ ਉਪਯੋਗੀ ਲੱਗੇ ਹੋਣਗੇ। ਤੁਸੀਂ ਲੇਖ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਸਮੱਗਰੀਆਂ ਨੂੰ ਇੱਥੇ ਵੀ ਲੱਭ ਸਕਦੇ ਹੋ YouTube ਅਤੇ ਸਲਾਈਡਾਂ ਵਿੱਚ DevOps Gathering 2019 ਵਿੱਚ ਮੇਰੀ ਗੱਲਬਾਤ.

ਕੁਬਰਨੇਟਸ 'ਤੇ ਕਲਾਉਡ ਖਰਚਿਆਂ ਨੂੰ ਬਚਾਉਣ ਲਈ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਕੀ ਹਨ? ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ 'ਤੇ ਦੱਸੋ ਟਵਿੱਟਰ (@try_except_).

[1] ਵਾਸਤਵ ਵਿੱਚ, 3 ਤੋਂ ਘੱਟ vCPUs ਵਰਤੋਂ ਯੋਗ ਰਹਿਣਗੇ ਕਿਉਂਕਿ ਨੋਡ ਦਾ ਥ੍ਰੋਪੁੱਟ ਰਾਖਵੇਂ ਸਿਸਟਮ ਸਰੋਤਾਂ ਦੁਆਰਾ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਭੌਤਿਕ ਨੋਡ ਸਮਰੱਥਾ ਅਤੇ "ਪ੍ਰਬੰਧਿਤ" ਸਰੋਤਾਂ ਵਿਚਕਾਰ ਫਰਕ ਕਰਦਾ ਹੈ (ਨੋਡ ਅਲਾਕੇਟੇਬਲ).

[2] ਗਣਨਾ ਉਦਾਹਰਨ: 5 GiB ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਇੱਕ m8.large ਉਦਾਹਰਨ ~$84 ​​ਪ੍ਰਤੀ ਮਹੀਨਾ ਹੈ (eu-central-1, ਆਨ-ਡਿਮਾਂਡ), ਯਾਨੀ. 1/8 ਨੋਡ ਨੂੰ ਬਲਾਕ ਕਰਨਾ ਲਗਭਗ ~$10/ਮਹੀਨਾ ਹੈ।

[3] ਤੁਹਾਡੇ EC2 ਬਿੱਲ ਨੂੰ ਘਟਾਉਣ ਦੇ ਹੋਰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਰਿਜ਼ਰਵਡ ਇੰਸਟੈਂਸ, ਸੇਵਿੰਗਜ਼ ਪਲਾਨ, ਆਦਿ। - ਮੈਂ ਇੱਥੇ ਉਹਨਾਂ ਵਿਸ਼ਿਆਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਾਂਗਾ, ਪਰ ਤੁਹਾਨੂੰ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ!

ਕੋਰਸ ਬਾਰੇ ਹੋਰ ਜਾਣੋ।

ਸਰੋਤ: www.habr.com