Kubernetes ਕੀ ਹੈ, ਅਤੇ ਇਹ ਅਕਸਰ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਕਿਉਂ ਹੁੰਦਾ ਹੈ

ਇਹ ਸਵਾਲ ਕਿਉਂ ਮਹੱਤਵਪੂਰਣ ਹੈ

“ਕੀ ਸਾਨੂੰ ਸੱਚਮੁਚ Kubernetes ਦੀ ਲੋੜ ਹੈ?” ਇਹ ਉਹਨਾਂ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਪੁੱਛਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਆਪਣੀ ਐਪ ਨੂੰ ਕੰਟੇਨਰਾਈਜ਼ ਕਰਣ ਜਾਂ ਕਲਾਉਡ 'ਤੇ ਲਿਜਾਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦੀਆਂ ਹਨ।

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

Kubernetes ਫਾਇਦੇਮੰਦ ਹੈ, ਪਰ ਇਹ ਡੀਫ਼ੌਲਟ ਨਹੀਂ ਹੈ

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਸੇਵਾਵਾਂ ਹਨ, ਬਾਰੰਬਾਰ ਰਿਲੀਜ਼ ਹਨ, ਅਤੇ ਸੁਪਰ-ਸਪਸ਼ਟ ਓਪਰੇਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ ਹਨ (auto-scaling, rollouts, self-healing, ਬਹੁ-ਟੀਮੀ ਮਲਕੀਅਤ), ਤਾਂ Kubernetes ਚਮਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਜੇ ਉਹ ਦਬਾਅ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰ ਰਹੇ, ਤਾਂ Kubernetes ਧੀਰੇ-ਧੀਰੇ ਧਿਆਨ ਭੰਗ ਕਰਨ ਵਾਲਾ ਬਣ ਸਕਦਾ ਹੈ: ਪਲੇਟਫਾਰਮ ਸਿੱਖਣ, ਕਲੱਸਟਰ ਮੁੱਦਿਆਂ ਦੀ ਡਿਬੱਗਿੰਗ, ਅਤੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਸਮਾਂ ਖਰਚ ਕਰਨਾ—ਇਹ ਸਾਰਾ ਸਮਾਂ ਉਤਪਾਦ ਨੂੰ ਸੁਧਾਰਨ ਦੀ ਬਜਾਏ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ।

ਇਹ ਲੇਖ ਇਹ ਨਹੀਂ ਕਿ "Kubernetes ਮਾੜਾ ਹੈ." ਇਹ ਹੈ: "Kubernetes ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ—ਅਤੇ ਸ਼ਕਤੀ ਦੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ।"

ਇਸ ਗਾਈਡ ਤੋਂ ਤੁਹਾਨੂੰ ਕੀ ਮਿਲੇਗਾ

ਅਖੀਰ ਤੱਕ, ਤੁਸੀਂ ਸਮਝ ਸਕੋਗੇ:

• ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ Kubernetes ਕੀ ਹੈ (ਕਾਫੀ ਤਾਂ ਜੋ ਤਕਨੀਕੀ ਗੱਲਬਾਤਾਂ ਨੂੰ ਸਮਝ ਸਕੋ)
• ਉਹ ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਛੁਪੇ ਖਰਚੇ ਜੋ ਇਕ ਛੋਟੀ ਪ੍ਰезੇਨਟੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੇ
• ਸਧਾਰਨ ਡਿਪਲੋਇਮੈਂਟ ਵਿਕਲਪ ਜੋ ਆਮ ਤੌਰ 'ਤੇ 80% ਫਾਇਦਾ 20% ਮਿਹਨਤ ਨਾਲ ਦੇਂਦੇ ਹਨ
• ਇੱਕ ਫੈਸਲਾ-ਚੈਕਲਿਸਟ ਕਿ Kubernetes ਤੁਹਾਡੇ ਅਸਲੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜਾਂ ਨਵੀਆਂ ਬਣਾਉਂਦਾ ਹੈ

ਜੇ ਤੁਹਾਡਾ ਮਕਸਦ "ਘੱਟ ਓਵਰਹੇਡ ਨਾਲ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ ਭੇਜਣਾ" ਹੈ, ਤਾਂ ਇਹ ਸਵਾਲ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿਉਂਕਿ Kubernetes ਇੱਕ ਸੰਭਵ ਜਵਾਬ ਹੈ—ਆਪਮੈਟਿਕ ਨਹੀਂ।

Kubernetes ਕੀ ਹੈ (ਸਧਾਰਨ ਪਰਿਭਾਸ਼ਾ)

Kubernetes (ਅਕਸਰ "K8s" ਆਖਿਆ ਜਾਂਦਾ) ਇੱਕ ਸਾਫਟਵੇਅਰ ਹੈ ਜੋ ਕੰਟੇਨਰਾਂ ਨੂੰ ਇੱਕ ਜਾਂ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚਲਾਉਂਦਾ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਕੰਟੇਨਰਾਂ ਵੱਜੋਂ ਪੈਕੇਜ ਕੀਤੀ ਗਈ ਹੈ (ਉਦਾਹਰਨ ਲਈ Docker ਨਾਲ), ਤਾਂ Kubernetes ਇਹ ਕੰਟੇਨਰ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਸਰਵਰ ਫੇਲ ਹੋਣ, ਟ੍ਰੈਫਿਕ ਵੱਧਣ ਜਾਂ ਤੁਸੀਂ ਨਵੀਆਂ ਵਰਜਨਾਂ ਨੂੰ ਰੋਲ ਆਉਟ ਕਰ ਰਹੇ ਹੋ।

"Orchestration" ਦਾ ਮਤਲਬ

ਤੁਸੀਂ Kubernetes ਨੂੰ ਕੰਟੇਨਰ ਓਰਕੈਸਟਰੇਸ਼ਨ ਵਜੋਂ ਸੁਣੋਗੇ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:

• ਕੰਟੇਨਰਾਂ ਨੂੰ ਸ਼ੈਡਿਊਲ ਕਰਨਾ (ਫੈਸਲਾ ਕਰਨਾ ਕਿ ਹਰ ਕੰਟੇਨਰ ਕਿੱਥੇ ਚੱਲੇ)
• ਸਕੇਲ ਉੱਪਰ ਜਾਂ ਹੇਠਾਂ (ਮੰਗ ਵਧਣ 'ਤੇ ਹੋਰ ਨਕਲਾਂ ਚਲਾਉਣਾ, ਗਿਰਣ 'ਤੇ ਘਟਾਉਣਾ)
• ਕੰਟੇਨਰ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਨਾ ਜਦੋਂ ਉਹ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ (ਅਤੇ ਗੈਰ-ਸਿਹਤਮੰਦ ਇਕਾਈਆਂ ਨੂੰ ਆਪਣੇ ਆਪ ਬਦਲਣਾ)
• ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਨੈੱਟਵਰਕਿੰਗ ਸੰਭਾਲਣਾ (ਤਾਂ ਜੋ ਕੰਟੇਨਰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਲੱਭ ਕੇ ਗੱਲ ਕਰ ਸਕਣ)
• ਅਪਡੇਟ ਰੋਲਆਉਟ ਕਰਨਾ ਹੌਲੇ-ਹੌਲੇ ਅਤੇ ਗਲਤੀ ਹੋਣ 'ਤੇ rollback ਕਰਨਾ

Kubernetes ਕੀ ਨਹੀਂ ਹੈ

Kubernetes ਕੋਈ ਵੈੱਬ ਫ੍ਰੇਮਵਰਕ, programming ਭਾਸ਼ਾ, ਜਾਂ ਜਾਦੂਈ ਪ੍ਰਦਰਸ਼ਨ ਬूसਟਰ ਨਹੀਂ ਹੈ। ਇਹ ਆਪੇ ਵਿੱਚ ਐਪ ਨੂੰ “ਚੰਗਾ” ਨਹੀਂ ਬਣਾਏਗਾ—ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਪਹਿਲਾਂ-ਤਿਆਰ ਕੀਤੇ ਐਪ ਨੂੰ ਚਲਾਉਣ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ।

ਇਹ Docker ਲਈ ਲਾਜ਼ਮੀ ਵੀ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ Docker ਕੰਟੇਨਰਾਂ ਨੂੰ ਇੱਕ ਹੀ ਸਰਵਰ (ਜਾਂ ਕੁਝ ਸਰਵਰਾਂ) 'ਤੇ Kubernetes ਦੇ ਬਿਨਾਂ ਚਲਾ ਸਕਦੇ ਹੋ। ਕਈ ਪ੍ਰੋਜੈਕਟ ਅਜਿਹਾ ਹੀ ਕਰਦੇ ਹਨ ਅਤੇ ਠੀਕ ਚੱਲਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ

ਕੰਟੇਨਰਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕਰਮਚਾਰੀਆਂ ਵਾਂਗ ਸੋਚੋ।

• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵਰਕਬੈਂਚ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਖੁਦ ਕੰਮ ਸੰਭਾਲ ਸਕਦੇ ਹੋ (ਇੱਕ ਸਰਵਰ, ਸਧਾਰਨ ਸੈਟਅਪ)।
• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਫੈਕਟਰੀ ਭਰੀ ਵਰਕਬੈਂਚਾਂ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮੈਨੇਜਰ ਦੀ ਲੋੜ ਹੋਏਗੀ ਜੋ ਟਾਸਕ ਸੌਂਪੇ, ਗੈਰਹਾਜ਼ਰ ਕਰਮਚਾਰੀਆਂ ਦੀ ਥਾਂ ਭਰੇ, ਅਤੇ ਉਤਪਾਦਨ ਚਲਾਉਂਦਾ ਰਹੇ।

Kubernetes ਉਹ ਫੈਕਟਰੀ ਮੈਨੇਜਰ ਹੈ—ਪੈਮਾਨੇ 'ਤੇ ਕੀਮਤੀ, ਪਰ ਅਕਸਰ ਇੱਕ ਛੋਟੀ ਦੁਕਾਨ ਲਈ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਪ੍ਰਬੰਧਨ।

ਮੁਢਲੇ ਇਮਾਰਤੀ ਹਿੱਸੇ ਜੋ ਤੁਸੀਂ ਸੁਣੋਂਗੇ

Kubernetes ਨਵੀਂ ਸ਼ਬਦਾਵਲੀ ਵਰਗੀ محسوس ਹੋ ਸਕਦੀ ਹੈ। ਚੰਗੀ ਖਬਰ: ਗੱਲਬਾਤ ਫੋਲੋ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹ ਉਹ ਆਬਜੈਕਟ ਹਨ ਜੋ ਤੁਸੀਂ ਲਗਭਗ ਹਰੇਕ Kubernetes ਚਰਚਾ 'ਚ ਸੁਣੋਗੇ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਸਧਾਰਨ ਮਤਲਬ।

Workloads: Pods ਅਤੇ Deployments

• Pod: ਸਭ ਤੋਂ ਛੋਟਾ runnable ਯੂਨਿਟ—ਅਮੂਮਨ ਇਕ ਕੰਟੇਨਰ (ਜਾਂ ਕੁਝ ਜੋ ਇਕੱਠੇ ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹੁੰਦੇ) ਜੋ ਇਕ ਇਕਾਈ ਵਜੋਂ ਚੱਲਦਾ ਹੈ।
• Deployment: "ਇਸ ਤਰ੍ਹਾਂ ਚਲਾਈਏ" ਦੀ ਹੁਕਮਨਾਮਾ—ਤੁਹਾਨੂੰ ਕਿੰਨੀ ਨਕਲਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਕਿਹੜੀ image ਚਲਾਨੀ ਹੈ, ਅਤੇ ਅਪਡੇਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਰੋਲ ਆਉਟ ਕਰਨਾ ਹੈ।
• Service: ਤੁਹਾਡੇ Pods ਲਈ ਇੱਕ ਸਥਿਰ ਦਰਵਾਜ਼ਾ—ਇਹ ਇੱਕ ਲਗਾਤਾਰ ਨਾਮ/IP ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਸਿਸਟਮ ਦੇ ਹੋਰ ਹਿੱਸੇ ਤੁਹਾਡੇ ਐਪ ਤੱਕ ਪਹੁੰਚ ਸਕਣ ਜਦ Pods ਆ ਰਹੇ ਜਾਂ ਜਾ ਰਹੇ ਹੋਣ।

ਜੇ ਤੁਸੀਂ Docker ਵਰਤਿਆ ਹੈ, ਤਾਂ Pod ਨੂੰ "ਇੱਕ container instance" ਸਮਝੋ, ਅਤੇ Deployment ਨੂੰ "ਉਹ ਪ੍ਰਣਾਲੀ ਜੋ N ਨਕਲਾਂ ਨੂੰ ਜਿਉਂਦਾ ਰੱਖਦੀ ਅਤੇ ਅਪਗਰੇਡ ਦੌਰਾਨ ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲਦੀ ਹੈ" ਦਰਸਾਉ।

ਟ੍ਰੈਫਿਕ ਲਿਆਉਣਾ: Ingress ਅਤੇ ਲੋਡ ਬੈਲੈਂਸਿੰਗ

Kubernetes "ਐਪ ਚਲਾਉਣ" ਨੂੰ "ਉਸ ਤੱਕ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰਾਹਦਾਰੀ ਕਰਨ" ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਬਾਹਰੀ ਟ੍ਰੈਫਿਕ ਇੱਕ Ingress ਰਾਹੀਂ ਪ੍ਰਵੇਸ਼ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਨਿਯਮ ਹੁੰਦੇ ਹਨ ਜਿਵੇਂ "/api ਲਈ ਬੇਨਤੀ API Service ਨੂੰ ਜਾਵੇ।" ਇੱਕ Ingress Controller (ਇੱਕ ਕੰਪੋਨੇਟ ਤੁਸੀਂ ਇੰਸਟਾਲ ਕਰਦੇ ਹੋ) ਉਹ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਕਸਰ ਇੱਕ ਕਲਾਉਡ ਲੋਡ ਬੈਲੈਂਸਰ ਨਾਲ ਜੋ ਇੰਟਰਨੈਟ ਤੋਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ।

ਸੰਰਚਨਾ: ConfigMaps ਅਤੇ Secrets

ਤੁਹਾਡੇ ਐਪ ਕੋਡ ਵਿੱਚ ਬਾਹਰੀ-ਵਾਤਾਵਰਣ-ਵਿਸ਼ੇਸ਼ ਸੈਟਿੰਗਾਂ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ। Kubernetes ਇਹਨਾਂ ਨੂੰ ਅਲੱਗ ਰੱਖਦਾ ਹੈ:

• ConfigMap: ਗੈਰ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੰਫਿਗuration ਜਿਵੇਂ feature flags, URLs, ਜਾਂ ਐਪ ਸੈਟਿੰਗਾਂ।
• Secret: ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲ ਜਿਵੇਂ API keys ਅਤੇ passwords (ਇਹ ਵੀ ਧਿਆਨ ਨਾਲ ਸੰਭਾਲੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ—"Secret" ਆਪਣੇ ਆਪ ਵਿੱਚ "ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ" ਨਹੀਂ ਦਿਖਾਇਆ ਰਿਹਾ)।

ਐਪ ਇਹਨਾਂ ਨੂੰ environment variables ਜਾਂ ਮਾਊਂਟ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਵਜੋਂ ਪੜ੍ਹਦੇ ਹਨ।

ਸੰਗਠਨ: Namespaces

ਇੱਕ Namespace ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਇੱਕ ਬਾਊਂਡਰੀ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਉਨ੍ਹਾਂ ਨੂੰ ਓਕਲਾਂ (dev/staging/prod) ਜਾਂ ਮਲਕੀਅਤ (team-a vs team-b) ਵੰਡਣ ਲਈ ਵਰਤਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਨਾਮ ਟਕਰਾਅ ਨਾ ਹੋਣ ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕੰਟਰੋਲ ਕੀਤਾ ਜਾ ਸਕੇ।

Kubernetes ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ

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

Self-healing

ਜੇ ਕੋਈ ਕੰਟੇਨਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, Kubernetes ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਰੀਸਟਾਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਕੋਈ ਪੂਰੀ ਮਸ਼ੀਨ (node) ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਉਹ ਵਰਕਲੋਡ ਇੱਕ ਸਿਹਤਮੰਦ ਨੋਡ 'ਤੇ ਰੀਸ਼ੈਡਿਊਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉਸ ਸਮੇਂ ਮਹੱਤਵਪੂਰਣ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਹ ਸੇਵਾਵਾਂ ਚਲਾ ਰਹੇ ਹੋ ਜੋ ਵਿਅਕਤੀਗਤ ਟੁੱਟਣਾਂ ਦੇ ਬਾਵਜੂਦ ਚੱਲਦੀਆਂ ਰਹਿਣੀ ਚਾਹੀਦੀਆਂ ਹਨ।

ਮੰਗ ਅਨੁਸਾਰ ਸਕੇਲਿੰਗ

Kubernetes ਲੋਡ ਦੇ ਆਧਾਰ 'ਤੇ ਸੇਵਾ ਦੀਆਂ ਹੋਰ (ਜਾਂ ਘੱਟ) ਨਕਲਾਂ ਚਲਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵਧਦੀ ਹੈ, ਤੁਸੀਂ replicas ਵਧਾ ਕੇ ਪ੍ਰਣਾਲੀ ਨੂੰ ਜਵਾਬਦੇਹ ਰੱਖ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਘੱਟ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਖਰਚ ਬਚਾਉਣ ਲਈ ਘੱਟ ਕਰ ਸਕਦੇ ਹੋ।

ਸੁਰੱਖਿਅਤ ਡਿਪਲੋਇਮੈਂਟ: rollouts ਅਤੇ rollbacks

ਇੱਕ ਸੇਵਾ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਔਫਲਾਇਨ ਲਿਆਉਣ ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ। Kubernetes ਧੀਰੇ-ਧੀਰੇ rollouts ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਥੋੜ੍ਹੀਆਂ ਨਕਲਾਂ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਬਦਲਨਾ)। ਜੇ ਨਵੀਂ ਵਰਜਨ ਗਲਤੀਆਂ ਲਿਆਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪਿਛਲੀ ਵਰਜਨ 'ਤੇ rollback ਕਰ ਸਕਦੇ ਹੋ।

ਸੇਵਾ-ਖੋਜ ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ

ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਸੀਂ ਹੋਰ ਕੰਪੋਨੈਂਟ ਜੋੜਦੇ ਹੋ, ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਲੱਭਣ ਅਤੇ ਗੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Kubernetes ਬਿਲਟ-ਇਨ ਸਰਵਿਸ ਡਿਸਕਵਰੀ ਅਤੇ ਸਥਿਰ ਨੈੱਟਵਰਕਿੰਗ ਪੈਟਰਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਕੰਪੋਨੈਂਟ ਇਕ-ਦੂਜੇ ਨਾਲ ਗੱਲ ਕਰ ਸਕਣ ਭਾਵੇਂ ਕੰਟੇਨਰ ਇਕੱਠੇ-ਇਕੱਠੇ ਤਬਦੀਲ ਹੁੰਦੇ ਰਹਿਣ।

ਕਈ ਸੇਵਾਵਾਂ ਅਤੇ ਟੀਮਾਂ ਦਾ ਪ੍ਰਬੰਧ

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

ਛੁਪੇ ਹੋਏ ਖਰਚੇ: ਜਟਿਲਤਾ ਅਤੇ ਸਮਾਂ

Kubernetes ਖੁੱਲ੍ਹੇ ਸੋర్స్ ਹੋਣ ਦੇ ਕਾਰਨ "ਮੁਫ਼ਤ" ਲੱਗ ਸਕਦਾ ਹੈ। ਪਰ ਅਸਲ ਕੀਮਤ ਧਿਆਨ ਵਿੱਚ ਹੋਣ ਵਿਚ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ: ਸਮਾਂ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਇਸਨੂੰ ਸਿੱਖਣ, ਕੰਫਿਗ ਕਰਨ, ਅਤੇ ਚਲਾਉਣ ਵਿੱਚ ਲਗਾਉਂਦੀ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਗਾਹਕਾਂ ਨੂੰ ਕੋਈ ਫਾਇਦਾ ਵੇਖਾਈ ਦੇਵੇ।

ਤੇਜ਼ ਸਿੱਖਣ ਦੀ ਢਲਾਣ (ਅਤੇ ਬਹੁਤ ਸਾਰੀ YAML)

ਅਨੁਭਵੀ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਵੀ, Kubernetes ਨਵੇਂ ਸੰਕਲਪਾਂ ਦਾ ਇੱਕ ਢੇਰ ਲਿਆਉਂਦਾ ਹੈ—Pods, Deployments, Services, Ingress, ConfigMaps, Namespaces, ਅਤੇ ਹੋਰ। ਇਹਦਾ ਬਹੁਤ ਸਾਰਾ ਹਿੱਸਾ YAML ਕੰਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜੋ ਨਕਲ-ਚਪਕਾਉਣ ਲਈ ਆਸਾਨ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਸਮਝਣ ਲਈ ਔਖਾ। ਛੋਟੇ ਬਦਲਾਅ ਵੀ ਅਚਾਨਕ ਪ੍ਰਭਾਵ ਲਿਆ ਸਕਦੇ ਹਨ, ਅਤੇ "ਚੱਲ ਰਹੇ" ਕੰਫਿਗ fragile ਹੋ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਮਜ਼ਬੂਤ ਰਿਵਾਜਾਂ ਦੇ।

ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੇਡ ਵਿਕਲਪਿਕ ਨਹੀਂ ਰਹਿੰਦਾ

Kubernetes ਚਲਾਉਣਾ ਮਤਲਬ ਇੱਕ ਕਲੱਸਟਰ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣਾ ਹੈ। ਇਸ ਵਿੱਚ ਅੱਪਗਰੇਡ, ਨੋਡ ਰੱਖ-ਰਖਾਅ, autoscaling ਵਰਤੋਂ, ਸਟੋਰੇਜ ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਬੈਕਅੱਪ, ਅਤੇ day-2 reliability ਕੰਮ ਸ਼ਾਮਿਲ ਹਨ। ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਤ observability (ਲੌਗ, ਮੈਟਰਿਕਸ, ਟਰੇਸ) ਅਤੇ ਅਲਰਟਿੰਗ ਦੀ ਲੋੜ ਹੋਏਗੀ ਜੋ ਦੋਹਾਂ—ਤੁਹਾਡੇ ਐਪ ਅਤੇ ਕਲੱਸਟਰ—ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਸਕੇ। Managed Kubernetes ਕੁਝ ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਨਾ ਹਟਾਉਂਦਾ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।

ਡਿਬੱਗਿੰਗ ਹੋ ਜਾਂਦੀ ਹੈ ਬਹੁਤ-ਪੱਧਰੀ

ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਕਾਰਨ ਤੁਹਾਡਾ ਕੋਡ ਹੋ ਸਕਦਾ ਹੈ, ਕੰਟੇਨਰ image, ਨੈੱਟਵਰਕ ਨਿਯਮ, DNS, ਇੱਕ ਫੇਲ ਨੋਡ, ਜਾਂ ਇੱਕ overloaded control plane ਕੰਪੋਨੇਟ। "ਅਸੀਂ ਕਿਥੇ ਵੇਖੀਏ?" ਵਾਲਾ ਪ੍ਰਸ਼ਨ ਅਸਲ ਵਿੱਚ ਦਰਪੇਸ਼ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਇਹ ਘਟਨਾ-ਜਵਾਬ ਨੂੰ ਸਲੋ ਕਰਦਾ ਹੈ।

ਵੱਡੀ ਸੁਰੱਖਿਆ ਸਤਹ

Kubernetes ਨਵੇਂ ਸੁਰੱਖਿਆ ਫੈਸਲੇ ਜੋੜਦਾ ਹੈ: RBAC permissions, secrets ਸੰਭਾਲ, admission ਨੀਤੀਆਂ, ਅਤੇ network policies। ਗਲਤ ਕੰਫਿਗਰੇਸ਼ਨ ਆਮ ਹਨ, ਅਤੇ defaults ਤੁਹਾਡੇ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਨਾਲ ਮਿਲ ਸਕਦੇ ਨਹੀਂ।

ਸਮਾਂ ਦੀ ਕੀਮਤ: ਮੁੱਲ ਭੇਜਣ ਲਈ ਧੀਮਾ ਹੋਣਾ

ਟੀਮਾਂ ਅਕਸਰ "ਪਲੇਟਫਾਰਮ" ਬਣਾਉਣ ਵਿੱਚ ਹਫ਼ਤਿਆਂ ਖਪਾਂਦੀਆਂ ਹਨ ਪਹਿਲਾਂ ਕਿ ਉਤਪਾਦ ਸੁਧਾਰਨ ਸ਼ੁਰੂ ਹੋਵੇ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਇਸ ਪੱਧਰ ਦੀ ਓਰਕੈਸਟਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ, ਤਾਂ ਇਹ ਉਹ momentum ਹੈ ਜੋ ਤੁਸੀਂ ਮੁੜ ਨਹੀਂ ਲੈ ਸਕੋਗੇ।

ਸੰਕੇਤ ਕਿ Kubernetes ਤੁਹਾਡੇ ਲਈ ਬੇਕਾਰ ਹੋ ਸਕਦਾ ਹੈ

Kubernetes ਉਹ ਵੇਲੇ ਚਮਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਹਲਚਲ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰ ਰਹੇ ਹੋ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਅਜੇ ਛੋਟਾ ਹੈ—ਜਾਂ ਹਫ਼ਤੇਵਾਰ ਬਦਲ ਰਿਹਾ ਹੈ—ਤਾਂ "ਪਲੇਟਫਾਰਮ" ਹੀ ਪ੍ਰੋਜੈਕਟ ਬਣ ਸਕਦਾ ਹੈ।

1) ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਟੀਮ (ਜਾਂ ਇਕੱਲੇ ਡਿਵ) ਹੋ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਚਲਾ ਰਹੇ ਹੋ

ਜੇ ਉਹੀ ਵਿਅਕਤੀ ਜੋ ਫੀਚਰ ਬਣਾਉਂਦਾ ਹੈ 2 ਵਜੇ ਰਾਤ ਨੂੰ ਨੈੱਟਵਰਕ, ਸਰਟੀਫਿਕੇਟ, ਡਿਪਲੋਇਮੈਂਟ, ਅਤੇ ਨੋਡ ਮੁੱਦਿਆਂ ਦੀ ਡਿਬੱਗਿੰਗ ਵੀ ਕਰਦਾ ਹੈ, ਤਾਂ Kubernetes momentum ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। Managed Kubernetes ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਤੁਸੀਂ ਕਲੱਸਟਰ-ਸਤਰ ਦੇ ਫੈਸਲੇ ਅਤੇ ਫੇਲ੍ਹਾਂ ਨਾਲ ਨਜਿੱਠਦੇ ਰਹੋਗੇ।

2) ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਜਾਂ ਦੋ ਸੇਵਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਅੰਦਾਜ਼ੇਯੋਗ ਹੈ

ਇੱਕ ਸਿੰਗਲ API ਅਤੇ ਇੱਕ worker, ਜਾਂ ਇੱਕ ਵੈੱਬ ਐਪ ਅਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਕੰਟੇਨਰ ਓਰਕੈਸਟਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰਖਦੇ। ਇੱਕ VM ਨਾਲ process manager, ਜਾਂ ਇੱਕ ਸਧਾਰਨ container ਸੈਟਅਪ, ਚਲਾਉਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਸੌਖਾ ਹੋ ਸਕਦਾ ਹੈ।

3) ਤੁਹਾਡਾ ਉਤਪਾਦ ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਿਹਾ ਹੈ

ਜਦੋਂ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਮੰਗੇ ਬਦਲ ਰਹੀਆਂ ਹਨ, Kubernetes ਅਗਲੇ ਪੱਧਰ 'ਤੇ ਜਲਦੀ ਨਿਯਮਿਤ ਕਰਨ ਦੀ ਪ੍ਰਗਟਾਵਾ ਕਰਦਾ ਹੈ: Helm charts, manifests, ingress ਨਿਯਮ, resource limits, namespaces, ਅਤੇ CI/CD ਪਲੰਬਿੰਗ। ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਉਤਪਾਦ ਨੂੰ ਪਰਖਣ ਵਿੱਚ ਨਹੀਂ ਲਗਦਾ।

4) ਤੁਹਾਡੇ ਵਰਕਲੋਡ ਇੱਕ VM 'ਤੇ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ (ਜਾਂ ਸਧਾਰਨ autoscaling)

ਜੇ vertical scaling (ਵੱਡੀ ਮਸ਼ੀਨ) ਜਾਂ 基本 horizontal scaling (ਕੁਝ replicas ਇੱਕ load balancer ਪਿੱਛੇ) ਤੁਹਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਤਾਂ Kubernetes ਸੇਟਅਪ ਕਰਨ ਨਾਲ ਸਿਰਫ਼ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦਾ ਝੰਝਟ ਵੱਧ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਵਧੀਆ ਲਾਭ ਦੇ।

5) ਤੁਹਾਡੇ ਕੋਲ platform ਮੁੱਦਿਆਂ ਲਈ on-call ਸਮਰੱਥਾ ਨਹੀਂ ਹੈ

ਕਲੱਸਟਰ ਅਣਜਾਣ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ: ਗਲਤ DNS, image pull errors, ਨੋਡ ਡਿਸਰਪਸ਼ਨ, noisy neighbors, ਜਾਂ ਅਪਡੇਟ ਜੋ ਅਨੁਮਿਤ ਤਰੀਕੇ ਨਾਲ ਚੱਲਦਾ ਹੈ। ਜੇ ਕੋਈ ਵਿਅਕਤੀ ਹਮੇਸ਼ਾ ਓਹਨਾਂ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਡਿਪਲੋਇਮੈਂਟਾਂ ਨੂੰ ਅਜੇ ਸਧਾਰਨ ਰੱਖੋ।

ਜਿਨ੍ਹਾਂ ਸਧਾਰਨ ਵਿਕਲਪਾਂ ਨਾਲ ਅਕਸਰ ਬਿਹਤਰ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ

Kubernetes ਉਸ ਵੇਲੇ ਚੰਗਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚਮੁਚ ਕਲੱਸਟਰ ਦੀ ਲੋੜ ਹੋਵੇ। ਪਰ ਬਹੁਤ ਤੀਮਾਂ ਇੱਕ ਸਧਾਰਨ ਡਿਪਲੋਇਮੈਂਟ ਮਾਡਲ ਨਾਲ 80–90% ਲਾਭ ਘੱਟ ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਨਾਲ ਹਾਸਲ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਮਕਸਦ ਨਿਰਾਸ਼ਾ-ਰਹਿਤ ਭਰੋਸੇਯੋਗਤਾ ਹੈ: ਪੂਰਵਾਨੁਮਾਨਯੋਗ deploys, ਆਸਾਨ rollbacks, ਅਤੇ ਘੱਟ "ਪਲੇਟਫਾਰਮ ਰੱਖ-ਰੱਖਾਅ"।

1) Single VM + systemd + Docker

ਛੋਟੇ ਉਤਪਾਦ ਲਈ, ਇੱਕ ਚੰਗਾ VM ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਟਿਕਾਊ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੀ ਐਪ Docker ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ, systemd ਨੂੰ ਇਸਨੂੰ ਜਿਊਂਦਾ ਰੱਖਣ ਦਿੰਦੇ ਹੋ, ਅਤੇ HTTPS ਅਤੇ ਰੂਟਿੰਗ ਲਈ ਇੱਕ reverse proxy (ਜਿਵੇਂ Nginx ਜਾਂ Caddy) ਵਰਤਦੇ ਹੋ।

ਇਹ ਸੈਟਅਪ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ, ਸਸਤਾ, ਅਤੇ ਡਿਬੱਗ ਕਰਨ ਵਿੱਚ ਤੇਜ਼ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਐਪ ਸਿਰਫ਼ ਇੱਕ ਥਾਂ 'ਤੇ ਹੋ ਸਕਦੀ ਹੈ। ਜਦ ਕੁਝ ਟੁੱਟੇ, ਤੁਸੀਂ SSH ਕਰਦੇ ਹੋ, ਲੌਗ ਦੇਖਦੇ ਹੋ, ਸਰਵਿਸ ਰੀਸਟਾਰਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਅੱਗੇ ਵਧਦੇ ਹੋ।

2) Docker Compose for multi-service apps

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵੈੱਬ ਐਪ, worker, ਡੇਟਾਬੇਸ, ਅਤੇ cache ਹਨ, ਤਾਂ Docker Compose ਅਕਸਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਕਈ ਸੇਵਾਵਾਂ ਨੂੰ ਇਕੱਠੇ ਚਲਾਉਣ, environment variables ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਅਤੇ ਮੂਲ ਨੈੱਟਵਰਕਿੰਗ ਸੰਭਾਲਣ ਲਈ ਇੱਕ ਦੁਹਰਾਯੋਗ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ।

ਇਹ 복잡 autoscaling ਜਾਂ multi-node scheduling ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰੇਗਾ—ਪਰ ਜ਼ਿਆਦातर ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦਾਂ ਨੂੰ ਐਸੇ ਹੱਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। Compose ਇਸ ਗੱਲ ਨੂੰ ਵੀ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ local development ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਨੇੜੇ ਰਹੇ ਬਗੈਰ ਪੂਰੇ orchestration ਪਲੇਟਫਾਰਮ ਨੂੰ ਜੋੜੇ।

3) Managed app platforms (PaaS)

ਜੇ ਤੁਸੀਂ ਸਰਵਰਾਂ 'ਤੇ ਘੱਟ ਸਮਾਂ ਖਰਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ PaaS "ਡਿਪਲੋਇਡ ਅਤੇ ਸਥਿਰ" ਤਕ ਪਹੁੰਚਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ (ਜਾਂ ਕੰਟੇਨਰ) ਪੁਸ਼ ਕਰਦੇ ਹੋ, environment variables ਸੈਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਰੂਟਿੰਗ, TLS, ਰੀਸਟਾਰਟ, ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸਕੇਲਿੰਗ ਚੀਜ਼ਾਂ ਹੱਲ ਕਰਦਾ ਹੈ।

ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਆਕਰਸ਼ਕ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਨਿਯੰਤਕ ops/platform ਇੰਜੀਨੀਅਰ ਨਹੀਂ ਹੈ।

4) Serverless for spiky or event-driven work

ਬੈਕਗ੍ਰਾਉਂਡ ਜੌਬ, scheduled tasks, webhooks, ਅਤੇ ਬਰਸਟਯੋਗ ਟ੍ਰੈਫਿਕ ਲਈ, serverless ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਝੰਝਟ ਘਟਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੇਵਲ execution ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਕੇਲਿੰਗ ਆਪਣੇ ਆਪ ਹੁੰਦੀ ਹੈ।

ਇਹ ਹਰ ਵਰਕਲੋਡ ਲਈ موزੂਨ ਨਹੀਂ ਹੈ (ਲੰਬੇ ਚੱਲਣ ਵਾਲੇ ਪ੍ਰੋਸੈਸ ਅਤੇ ਕੁਝ latency-sensitive ਸਿਸਟਮ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੇ ਹਨ), ਪਰ ਇਹ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਈ ਬੜੀਆਂ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਫੈਸਲਿਆਂ ਨੂੰ ਹਟਾ ਸਕਦਾ ਹੈ।

5) Managed container services (ਬਿਨਾਂ “Kubernetes ਚਲਾਉਣ”)

ਕੁਝ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਤੁਹਾਨੂੰ ਕੰਟੇਨਰ ਚਲਾਉਣ ਦੀ ਆਸਾਨੀ ਦੇਂਦੇ ਹਨ—ਅੰਦਰੂਨੀ ਸਕੇਲਿੰਗ ਅਤੇ ਲੋਡ ਬੈਲੈਂਸਿੰਗ ਨਾਲ—ਪਰ ਕਲੱਸਟਰ, ਨੋਡ, ਜਾਂ Kubernetes ਅਪਗਰੇਡ ਤੁਹਾਨੂੰ ਚਲਾਉਣੇ ਨਹੀਂ ਪੈਂਦੇ। ਤੁਸੀਂ ਕੰਟੇਨਰ ਮਾਡਲ ਰੱਖਦੇ ਹੋ, ਪਰ ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਿੰਗ ਬਹੁਤ ਹੱਦ ਤੱਕ ਛੱਡ ਦਿੰਦੇ ਹੋ।

ਜੇ ਤੁਹਾਡਾ ਮੁੱਖ ਕਾਰਨ "ਅਸੀ ਕੰਟੇਨਰ ਚਾਹੁੰਦੇ ਹਾਂ" ਹੈ, ਤਾਂ ਇਹ ਅਕਸਰ ਸਧਾਰਨ ਜਵਾਬ ਹੁੰਦਾ ਹੈ।

Koder.ai ਕਿਸ ਤਰ੍ਹਾਂ "start simple" ਰਣਨੀਤੀ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

ਜੇ ਅਸਲ ਮਕਸਦ ਇੱਕ ਚੱਲਦੀ ਹੋਈ web/API/mobile ਪ੍ਰੋਡਕਟ ਭੇਜਣਾ ਹੈ ਬਿਨਾਂ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਮੁੱਖ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦੇ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ deployable baseline ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਐਪਸ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਆਮ ਸਟੈਕ ਵਰਗੇ React ਵੈੱਬ ਲਈ, Go + PostgreSQL ਬੈਕਐਂਡ/ਡੇਟਾ ਲਈ, ਅਤੇ Flutter ਮੋਬਾਈਲ ਲਈ ਉਪਲਬਧ ਹਨ।

Kubernetes ਦੀ ਗੱਲ ਵਿੱਚ ਪ੍ਰਯੋਗਿਕ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ:

• ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਸਾਫ, container-friendly ਆਰਕੀਟੈਕਚਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ (ਬਿਨਾਂ ਹਫ਼ਤਿਆਂ ਦੀ scaffolding)
• planning mode ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੇਵਾਵਾਂ ਅਤੇ ਵਾਤਾਵਰਣ ਪਹਿਲਾਂ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ
• ਜਦੋਂ delivery ਪ੍ਰਕਿਰਿਆ ਹੋ ਰਹੀ ਹੋਵੇ, snapshots ਅਤੇ rollback 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਦੇ ਹੋ
• ਜਦੋਂ ਤਿਆਰ ਹੋ, source code export ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ CI/CD ਅਤੇ ਹੋਸਟਿੰਗ ਸੈਟਅਪ ਤੇ ਜਾ ਸਕਦੇ ਹੋ

ਦੂਸਰੇ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਤੁਸੀਂ Kubernetes ਨੂੰ ਤਦ ਹੀ ਲਾਗੂ ਕਰਨ ਦੀ ਦੇਰੀ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਇਸਦੀ ਜ਼ਰੂਰਤ ਸਾਬਤ ਹੋਵੇ—ਬਿਨਾਂ ਉਤਪਾਦ ਡਿਲੇ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਕੀਤੇ।

ਸਾਰੇ ਵਿਕਲਪਾਂ ਦੀ आम ਸੂਤ੍ਰ: ਸਭ ਤੋਂ ਛੋਟਾ ਟੂਲ ਵਰਤੋ ਜੋ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ ਡਿਪਲੋਇ ਕਰੇ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ Kubernetes ਵਿੱਚ ਗ੍ਰੈਜੂਏਟ ਕਰ ਸਕਦੇ ਹੋ—ਜਦੋਂ ਜਟਿਲਤਾ ਸੱਚਮੁਚ ਨਿਰਧਾਰਿਤ ਲੋੜਾਂ ਦੁਆਰਾ ਜਾਇਜ਼ ਹੋਵੇ, ਨਾ ਕਿ ਭਵਿੱਖ ਦੇ ਡਰ ਨਾਲ।

Kubernetes ਕਦੋਂ ਸਹੀ ਟੂਲ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਐਪ ਦੀ ਥਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਾਂਗ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, Kubernetes ਆਪਣੀ ਜਟਿਲਤਾ ਕਾਫੀ ਸਮਝਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਪਹਿਲਾਂ ਹੀ "ਇੱਕ ਸਰਵਰ ਤੋਂ ਵੱਡਾ" ਮਹਿਸੂਸ ਹੋ ਰਿਹਾ ਹੈ, Kubernetes ਤੁਹਾਨੂੰ ਕਈ ਚੱਲਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਚਲਾਉਣ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਦੇ ਸਕਦਾ ਹੈ।

ਤੁਸੀਂ ਕਈ ਸੇਵਾਵਾਂ ਚਲਾ ਰਹੇ ਹੋ

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ APIs, background workers, cron jobs, ਅਤੇ ਸਹਾਇਕ ਕੰਪੋਨੈਂਟ ਹਨ (ਅਤੇ ਉਨ੍ਹਾਂ ਸਭ ਨੂੰ ਇੱਕੋ deployment, health checks, ਅਤੇ rollback ਵਿਵਹਾਰ ਦੀ ਲੋੜ ਹੈ), ਤਾਂ Kubernetes ਤੁਹਾਨੂੰ ਹਰ ਸੇਵਾ ਲਈ ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਆਂ ਖੋਜਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਭੇਜਦੇ ਹੋ

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