Joe Beda ਦੇ ਸ਼ੁਰੂਆਤੀ Kubernetes ਚੋਣਾਂ — ਡਿਕਲੇਰਟਿਵ APIs, ਕੰਟਰੋਲ ਲੂਪ, Pods, Services ਅਤੇ ਲੇਬਲ — ਅਤੇ ਇਨ੍ਹਾਂ ਨੇ ਆਧੁਨਿਕ ਐਪ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਕਿਵੇਂ ਆਕਾਰ ਦਿੱਤਾ, ਇਸ 'ਤੇ ਸਪੱਸ਼ਟ ਨਜ਼ਰ।
Joe Beda Kubernetes ਦੇ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਇਨ ਦੇ ਮੁੱਖ ਲੋਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ—ਉਹਨਾਂ ਨੇ Google ਦੇ ਅੰਦਰੂਨੀ ਸਿਸਟਮਾਂ ਤੋਂ ਸਿੱਖਿਆ ਲੈ ਕੇ ਇੱਕ ਖੁੱਲ੍ਹਾ ਪਲੇਟਫਾਰਮ ਬਣਾਇਆ। ਉਹ ਫੈਸਲੇ ਨਵੇਂ ਟ੍ਰੈਂਡੀ ਫੀਚਰਾਂ ਤੱਕ ਪਿੱਛੇ ਨਹੀਂ ਸੀ; ਇਹ ਸਧਾਰਨ ਪ੍ਰਮਿਟਿਵ ਚੁਣਨ ਬਾਰੇ ਸੀ ਜੋ ਹਕੀਕਤੀ ਉਤਪਾਦਨ ਵਾਲੀ ਅਗਵਾਈ ਨੂੰ ਸਹਿਣ ਕਰ ਸਕਣ ਅਤੇ ਆਮ ਟੀਮਾਂ ਲਈ ਸਮਝਣ ਯੋਗ ਰਹਿਣ।
ਇਹ ਸ਼ੁਰੂਆਤੀ ਫੈਸਲੇ ਇਸ ਲਈ ਹਨ ਕਿ Kubernetes ਸਿਰਫ਼ “ਇੱਕ ਕਨਟੇਨਰ ਟੂਲ” ਬਣ ਕੇ ਰਹਿ ਨਾ ਜਾਵੇ। ਇਹ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਕੋਰ ਬਣ ਗਿਆ।
“ਕਨਟੇਨਰ ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ” ਨਿਯਮਾਂ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਚੱਲਦਾ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਮਸ਼ੀਨਾਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਟ੍ਰੈਫਿਕ ਵਧ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਨਵੀਂ ਵਰਜਨ ਡਿਪਲੋਇਟ ਕਰਦੇ ਹੋ। ਮਨੁੱਖੀ ਤੌਰ 'ਤੇ ਸਰਵਰਾਂ ਨੂੰ ਦੇਖਭਾਲ ਕਰਨ ਦੀ ਥਾਂ, ਸਿਸਟਮ ਕਨਟੇਨਰਾਂ ਨੂੰ ਕੰਪਿਊਟਰਾਂ 'ਤੇ ਸ਼ੈਡਿਊਲ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਉਹ ਗਿਰ ਜਾਂਦੇ ਹਨ ਤਦ ਉਹਨਾਂ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈ, ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਉਹਨਾਂ ਨੂੰ ਫੈਲਾਂਦਾ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ ਸੈੱਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਣ।
Kubernetes ਆਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਟੀਮਾਂ ਅਕਸਰ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਕਸਟਮ ਟੂਲਾਂ ਨੂੰ ਜੋੜ ਕੇ ਇੱਕ-ਦੋ ਮੁੱਦੇ ਹੱਲ ਕਰਦੀਆਂ ਸਨ:
ਉਹ DIY ਸਿਸਟਮ ਕੰਮ ਕਰਦੇ ਸਨ—ਜਦ ਤੱਕ ਉਹ ਨਹੀਂ ਕਰਦੇ। ਹਰ ਨਵਾਂ ਐਪ ਜਾਂ ਟੀਮ ਹੋਰ ਇੱਕ-ਆਫ਼ ਲਾਜ਼ਮਿਕਤਾ ਜੋੜ ਦਿੰਦੀ ਸੀ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਕੁਨਸਿਸਟੈਂਸੀ ਪانا ਔਖਾ ਹੋ ਗਿਆ।
Kubernetes ਦਾ ਮਕਸਦ ਇੱਕ ਹੀ, ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਓਪਰੇਸ਼ਨਲ ਲੋੜਾਂ ਨੂੰ ਦਰਸਾਉਣਾ ਸੀ, ਭਾਵੇਂ ਮਸ਼ੀਨਾਂ ਕਿੱਥੇ ਵੀ ਰਹਿਣ।
ਡਿਵੈਲਪਰ ਚਾਹੁੰਦੇ ਸਨ self-service: ਬਿਨਾਂ ਟਿਕਟ ਦੇ deploy, ਬਿਨਾਂ ਇੱਜਤ ਮੰਗਣ ਦੇ scale, ਅਤੇ drama-ਬਿਨਾਂ rollback। Ops ਟੀਮਾਂ ਚਾਹੁੰਦੀਆਂ ਹਨ predictability: standardized health checks, repeatable deployments, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਸਰੋਤ-ਸੱਚ ਜੋ ਦੱਸੇ ਕਿ ਕੀ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ।
Kubernetes ਕਿਸੇ fancy scheduler ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ—ਇਹ ਇੱਕ ਭਰੋਸੇਯੋਗ ਐਪਲੀਕੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਦਾ ਨਿਵਾੜਾ ਬਣਨਾ ਚਾਹੁੰਦਾ ਸੀ—ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਜੋ ਗੰਦੇ ਹਕੀਕਤ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਢਾਲ ਦੇਵੇ ਕਿ ਤੁਸੀਂ ਉਸ 'ਤੇ ਸੋਚ ਸਕੋ।
ਸ਼ੁਰੂਆਤੀ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਫੈਸਲਿਆਂ ਵਿਚ ਇਕ ਸੀ Kubernetes ਨੂੰ ਡਿਕਲੇਰਟਿਵ ਬਣਾਉਣਾ: ਤੁਸੀਂ ਉਹ ਦੱਸਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਸਿਸਟਮ ਹਕੀਕਤ ਨੂੰ ਉਸ ਵਰਣਨ ਦੇ ਅਨੁਸਾਰ ਮਿਲਾਉਂਦਾ ਹੈ।
Thermostat ਇੱਕ ਵਰਤੇ ਜਾਣ ਵਾਲਾ ਉਦਾਹਰਨ ਹੈ। ਤੁਸੀਂ ਹਰ ਕੁਝ ਮਿੰਟਾਂ 'ਤੇ ਹੀਟਰ ਨੂੰ ਆਨ/ਆਫ਼ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ ਇਕ ਚਾਹੀਦਾ ਤਾਪਮਾਨ (ਜਿਵੇਂ 21°C) ਸੈੱਟ ਕਰਦੇ ਹੋ—ਅਤੇ thermostat ਕਮਰੇ ਦੀ ਜਾਂਚ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਹੀਟਰ ਨੂੰ ਢੰਗ ਨਾਲ ਐਡਜਸਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਟਾਰਗਟ ਦੇ ਨੇੜੇ ਰਹੇ।
Kubernetes ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੁਰਤ-ਤੁਰਤ ਕਲੱਸਟਰ ਨੂੰ ਇਹ ਨਾ ਦੱਸੋ, “ਇਸ ਮਸ਼ੀਨ 'ਤੇ ਏ ਕਨਟੇਨਰ ਚਲਾਓ, ਫਿਰ ਜੇ ਇਹ ਫੇਲ ਹੋਏ ਤਾਂ ਰੀਸਟਾਰਟ ਕਰੋ”; ਬਲਕਿ ਨਤੀਜਾ ਡਿਕਲੇਅਰ ਕਰੋ: “ਮੈਨੂੰ ਇਸ ਐਪ ਦੀ 3 ਕਾਪੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।” Kubernetes ਲਗਾਤਾਰ ਦੇਖਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਡ੍ਰਿਫ਼ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ।
ਡਿਕਲੇਰਟਿਵ ਕੰਫ਼ਿਗਰੇਸ਼ਨ ਉਹ ਛੁਪੇ "ops ਚੈਕਲਿਸਟ" ਘੱਟ ਕਰ ਦਿੰਦਾ ਜੋ ਅਕਸਰ ਕਿਸੇ ਦੇ ਸਿਰ ਵਿੱਚ ਜਾਂ ਕਿਸੇ ਅਧ-ਅਪਡੇਟ ਕੀਤੇ runbook ਵਿੱਚ ਰਿਹਾਂਦਾ ਹੈ। ਤੁਸੀਂ config apply ਕਰਦੇ ਹੋ, ਅਤੇ Kubernetes ਪਲੇਸਮੈਂਟ, ਰੀਸਟਾਰਟ, ਅਤੇ ਕਨਸਿਲੀਏਸ਼ਨ ਦੀ ਮਕੈਨਿਕ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।
ਇਸ ਨਾਲ ਬਦਲਾਅ ਨੂੰ ਰਿਵਿਊ ਕਰਨਾ ਵੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ—ਇੱਕ ਬਦਲਾਅ configuration ਵਿੱਚ diff ਵਜੋਂ ਦਿਸਦਾ ਹੈ, ਨਾ ਕਿ ਕਈ ਐਡ‑ਹੋਕ ਕਮਾਂਡਾਂ ਵਜੋਂ।
ਕਿਉਂਕਿ desired state ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਤੁਸੀਂ ਉਹੀ ਦ੍ਰਿਸ਼ਟੀ dev, staging ਅਤੇ production ਵਿੱਚ ਦੁਹਰਾਉਂ ਸਕਦੇ ਹੋ। ਮਹੌਲ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਰਾਦਾ ਲਗਾਤਾਰ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਡਿਪਲੋਇਮੈਂਟਸ ਨੂੰ ਜਿਆਦਾ ਪੇਸ਼ਗੋਈਯੋਗ ਅਤੇ ਆਡੀਟ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਡਿਕਲੇਰਟਿਵ ਸਿਸਟਮਾਂ ਦੀ ਇੱਕ ਲਰਨਿੰਗ ਕਰਵ ਹੈ: ਤੁਹਾਨੂੰ “ਕੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ” ਵਿੱਚ ਸੋਚਣਾ ਪੈਂਦਾ ਹੈ ਨਾ ਕਿ “ਅਗਲਾ ਕਦਮ ਕੀ ਕਰਨਾ ਹੈ।” ਇਹ ਚੰਗੀਆਂ ਡਿਫਾਲਟਸ ਅਤੇ ਸਪਸ਼ਟ ਕੰਵੇਂਸ਼ਨਾਂ 'ਤੇ ਭਾਰੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ—ਬਿਨਾਂ ਇਹਨਾਂ ਦੇ, ਟੀਮਾਂ ਐਸੀ configs ਬਣਾ ਸਕਦੀਆਂ ਹਨ ਜੋ ਤਕਨੀਕੀ ਰੂਪ ਵਿੱਚ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਪਰ ਸਮਝਣ ਅਤੇ ਰੱਖਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੋਣ।
Kubernetes ਇਸ ਲਈ کامیاب ਨਹੀਂ ਹੋਇਆ ਕਿ ਇਹ ਇਕ ਵਾਰੀ ਕਨਟੇਨਰ ਚਲਾ ਸਕਦਾ ਸੀ—ਇਹ ਇਸ ਲਈ کامیاب ਹੋਇਆ ਕਿ ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਵਕਤ ਦੇ ਨਾਲ ਠੀਕ ਰੱਖ ਸਕਦਾ ਸੀ। ਵੱਡੀ ਡਿਜ਼ਾਇਨ ਚਾਲ ਇਹ ਸੀ ਕਿ “control loops” (controllers) ਸਿਸਟਮ ਦੇ ਕੋਰ ਇੰਜਿਨ ਬਣੇ।
Controller ਇੱਕ ਸਧਾਰਨ ਲੂਪ ਹੁੰਦਾ ਹੈ:
ਇਹ ਇੱਕ ਵਾਰ ਦੀ ਟਾਸਕ ਵਾਂਗ ਨਹੀਂ, ਬਲਕਿ autopilot ਵਾਂਗ ਹੈ। ਤੁਸੀਂ ਵਰਕਲੋਡਜ਼ ਦੀ dekhbhaal ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਡਿਕਲੇਅਰ ਕਰਦੇ ਹੋ, ਅਤੇ controllers ਕਲੱਸਟਰ ਨੂੰ ਉਸ ਨਤੀਜੇ ਵੱਲ ਮੁੜ-ਮੁੜ ਸਟੀਅਰ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।
ਇਹ ਪੈਟਰਨ ਉਹ ਕਾਰਨ ਹੈ ਕਿ Kubernetes ਅਸਲ-ਦੁਨੀਆ ਦੀਆਂ ਪ੍ਰੇਸ਼ਾਨੀਆਂ 'ਤੇ resilient ਹੁੰਦਾ ਹੈ:
ਫੇਲਯੂਰਜ਼ ਨੂੰ ਖ਼ਾਸ ਮਾਮਲੇ ਵਜੋਂ ਦੇਖਣ ਦੀ ਥਾਂ, controllers ਉਨ੍ਹਾਂ ਨੂੰ routine "state mismatch" ਸਮਝ ਕੇ ਹਰ ਵਾਰੀ ਇਕੋ ਢੰਗ ਨਾਲ ਠੀਕ ਕਰਦੇ ਹਨ।
ਪੁਰਾਣੀਆਂ automation ਸਕ੍ਰਿਪਟਾਂ ਅਕਸਰ ਇੱਕ ਸਥਿਰ ਮਹੌਲ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ: ਪਹਿਲਾਂ A ਚਲਾਓ, ਫਿਰ B, ਫਿਰ C। ਵਿਤਰਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਇਹ ਧਾਰਣਾਵਾਂ ਬਰਬਾਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। Controllers ਇਸ ਲਈ ਬਿਹਤਰ ਸਕੇਲ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ idempotent ਹਨ (ਬਾਰ-ਬਾਰ ਚਲਾਉਣ 'ਤੇ ਵੀ ਸੁਰੱਖਿਅਤ) ਅਤੇ eventually consistent ਹਨ (ਉਹ ਟарਗਟ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ)।
ਜੇ ਤੁਸੀਂ ਇੱਕ Deployment ਵਰਤਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ control loops 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋ। ਅੰਦਰੋਂ Kubernetes ਇੱਕ ReplicaSet controller ਵਰਤਦਾ ਹੈ ਤਾਂ ਕਿ ਮੰਗੀ ਗਈ ਗਿਣਤੀ ਪਾਡਸ ਦੀ ਯਕੀਨੀ ਬਣੇ—ਅਤੇ Deployment controller rolling updates ਅਤੇ rollbacks ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ।
Kubernetes ਸਿਰਫ਼ “ਕਨਟੇਨਰ” ਸ਼ੈਡਿਊਲ ਕਰ ਸਕਦਾ ਸੀ, ਪਰ Joe Beda ਦੀ ਟੀਮ ਨੇ Pods ਨੂੰ ਛੋਟਾ deployable ਯੂਨਿਟ ਬਣਾਇਆ ਜੋ ਕਲੱਸਟਰ ਇੱਕ ਨੋਡ 'ਤੇ ਰੱਖਦਾ ਹੈ। ਮੁੱਖ ਵਿਚਾਰ: ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਐਪ ਇਕੱਲੇ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇੱਕ ਛੋਟੇ ਗਰੁੱਪ ਹੁੰਦੇ ਹਨ ਜੋ ਇਕੱਠੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।
Pod ਇੱਕ ਜਾਂ ਵੱਧ ਕੰਟੇਨਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਰੈਪਰ ਹੈ ਜੋ ਇਕੋ ਨਸੀਬ ਸਾਂਝਾ ਕਰਦੇ ਹਨ: ਉਹ ਇਕੱਠੇ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, একই ਨੋਡ 'ਤੇ ਚਲਦੇ ਹਨ, ਅਤੇ ਇਕੱਠੇ ਸਕੇਲ ਹੁੰਦੇ ਹਨ। ਇਸ ਨਾਲ sidecars ਦੇ ਪੈਟਰਨ ਕੁਦਰਤੀ ਬਣ ਜਾਂਦੇ ਹਨ—ਲੌਗ ਸ਼ਿਪਰ, ਪ੍ਰਾਕਸੀ, ਕੰਫਿਗ ਰੀਲੋਡਰ, ਜਾਂ ਸੁਰੱਖਿਆ ਏਜੰਟ ਜੋ ਮੁੱਖ ਐਪ ਨਾਲ ਸਦਾ ਰਹਿਣੇ ਹੋਣ।
ਸਹਾਇਕਾਂ ਨੂੰ ਹਰ ਐਪ ਵਿੱਚ ਇੰਟੇਗਰੇਟ ਕਰਨ ਦੀ ਥਾਂ, Kubernetes ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਕੰਟੇਨਰ ਵਜੋਂ ਪੈਕੇਜ ਕਰਨ ਦਿੰਦਾ ਹੈ ਪਰ ਉਹ ਇੱਕ ਯੂਨਿਟ ਵਰਗੇ ਵਰਤਦੇ ਹਨ।
Pods ਦੋ ਮਹੱਤਵਪੂਰਨ ਧਾਰਣਾਵਾਂ ਨੂੰ ਪ੍ਰਯੋਗਯੋਗ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ:
localhost ਉੱਤੇ ਗੱਲਬਾਤ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਸਧਾਰਨ ਅਤੇ ਤੇਜ਼ ਹੈ।ਇਹ ਚੋਣਾਂ ਕਸਟਮ ਗਲੂ ਕੋਡ ਦੀ ਲੋੜ ਘੱਟ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਪ੍ਰਕਿਰਿਆ-ਸਤਰ ਤੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਅਲੱਗ ਰੱਖਦੀਆਂ ਹਨ।
ਨਵੇਂ ਯੂਜ਼ਰ ਅਕਸਰ ਸੋਚਦੇ ਹਨ "ਇੱਕ ਕੰਟੇਨਰ = ਇੱਕ ਐਪ", ਫਿਰ Pod-ਸਤਰੀ ਧਾਰਣਾਵਾਂ: restarts, IPs, ਅਤੇ ਸਕੇਲਿੰਗ ਨਾਲ ਠਹਿਰ ਜਾਂਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਪਲੇਟֆਾਰਮ ਇਸਨੂੰ ਸਲਿੱਪਰ ਕਰਦੇ ਹਨ Opinionated templates ਦੇ ਕੇ (ਉਦਾਹਰਨ: “web service”, “worker”, ਜਾਂ “job”) ਜੋ ਪਿੱਛੇ Pods ਜਨਰੇਟ ਕਰਦੇ ਹਨ—ਤਾਂ ਜੋ ਟੀਮਾਂ ਨੂੰ sidecars ਅਤੇ ਸਾਂਝੇ ਸਰੋਤਾਂ ਦੇ ਫਾਇਦੇ ਮਿਲ ਸਕਣ ਬਿਨਾਂ ਹਰ ਰੋਜ਼ Pod ਮਕੈਨਿਕ ਦੇ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੋਵੇ।
Kubernetes ਵਿੱਚ ਇਕ ਸ਼ਾਂਤ ਪਰ ਤਾਕਤਵਰ ਚੋਣ ਇਹ ਸੀ ਕਿ labels ਨੂੰ ਪਹਿਲ-ਪੈਦਾ metadata ਮੰਨਿਆ ਗਿਆ ਅਤੇ selectors ਨੂੰ ਚੀਜ਼ਾਂ ਨੂੰ "ਲੱਭਣ" ਦਾ ਮੁੱਖ ਤਰੀਕਾ ਬਣਾਇਆ ਗਿਆ। ਸਥਿਰ ਹੋਸਟ ਲਿਸਟਾਂ (ਜਿਵੇਂ "ਇਹ ਤਿੰਨ ਮਸ਼ੀਨਾਂ ਮੇਰਾ ਐਪ ਚਲਾਉਂਦੀਆਂ ਹਨ") ਦੀ ਥਾਂ, Kubernetes ਤੁਹਾਨੂੰ attribute ਨਾਲ ਗਰੁੱਪ ਵਰਣਨ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ।
Label ਇੱਕ ਸਧਾਰਨ key/value ਜੋੜ ਹੈ ਜੋ ਤੁਸੀਂ resources ਉੱਤੇ ਲਗਾ ਸਕਦੇ ਹੋ—Pods, Deployments, Nodes, Namespaces, ਆਦਿ। ਉਹ ਇੱਕ ਸਥਿਰ, ਕਵੈਰੀਯੋਗ "ਟੈਗ" ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ:
app=checkoutenv=prodtier=frontendਕਿਉਂਕਿ labels ਹਲਕੇ ਅਤੇ ਯੂਜ਼ਰ-ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਆਪਣੀ ਸੰਸਥਾ ਦੀ ਹਕੀਕਤ ਨੂੰ ਮਾਡਲ ਕਰ ਸਕਦੇ ਹੋ: ਟੀਮਾਂ, ਲਾਗਤ-ਕੇਂਦਰ, ਅਨੁਸਰਨ ਖੇਤਰ, ਰਿਲੀਜ਼ ਚੈਨਲ, ਜਾਂ ਜੋ ਕੁਝ ਵੀ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
Selectors ਲੇਬਲਾਂ ਉੱਤੇ ਕਵੈਰੀਆਂ ਹਨ (ਉਦਾਹਰਨ: “ਸਾਰੇ Pods ਜਿੱਥੇ app=checkout ਅਤੇ env=prod”)। ਇਹ ਫਿਕਸਡ ਹੋਸਟ ਲਿਸਟਾਂ ਨਾਲੋਂ ਬੇਹਤਰ ਹੈ ਕਿਉਂਕਿ ਸਿਸਟਮ ਅਨੁਕੂਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ Pods ਨੂੰ ਨਵਾਂ-ਨਵਾਂ ਰੀਸਕੇਡਿਊਲ, ਸਕੇਲ-ਅੱਪ/ਡਾਊਨ, ਜਾਂ ਰੋਲਆਉਟ ਦੌਰਾਨ ਬਦਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੀ configuration ਅਸਥਿਰ ਰਹਿੰਦੀ ਹੈ ਭਾਵੇਂ ਅੰਡਰਲਾਇੰਗ ਇੰਸਟੈਂਸ ਲਗਾਤਾਰ ਬਦਲ ਰਹੇ ਹਨ।
ਇਹ ਡਿਜ਼ਾਇਨ ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ ਇੰਸਟੈਂਸ ਪਹਿਚਾਨ ਨਹੀਂ ਕਰਦੇ—ਤੁਸੀਂ ਕੁਝ ਤੇਲਮੀ ਲੇਬਲ ਸੈਟਸ ਮੈਨੇਜ ਕਰਦੇ ਹੋ। ਇਹ loose coupling ਦਾ ਅਸਲ ਮਤਲਬ ਹੈ: ਕੰਪੋਨੈਂਟ ਉਸ ਗਰੁੱਪ ਨਾਲ ਜੁੜਦੇ ਹਨ ਜਿਹਦਾ ਮੈਂਬਰਸ਼ਿਪ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ।
ਲੇਬਲ ਇੱਕ ਵਾਰ ਆ ਜਾਂਦੀਆਂ ਹਨ, ਤਦ ਇਹ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਸਾਂਝੀ ਜ਼ਬਾਨ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ traffic routing (Services), policy ਹੱਦਾਂ (NetworkPolicy), observability filters (metrics/logs), ਅਤੇ ਕਿਰਕੇ ਦਰਜਾ-ਟ੍ਰੈਕਿੰਗ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ—ਚੀਜ਼ਾਂ ਨੂੰ ਮੁਕੱਦਰ ਤਰੀਕੇ ਨਾਲ ਟੈਗ ਕਰੋ—ਪੂਰੇ ਆਟੋਮੇਸ਼ਨ ਐਕੋਸਿਸਟਮ ਨੂੰ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ।
Kubernetes ਨੂੰ ਇੱਕ ਤਰੀਕਾ ਚਾਹੀਦਾ ਸੀ ਤਾਂ ਜੋ ਨੈੱਟਵਰਕਿੰਗ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੋਵੇ ਭਾਵੇਂ ਕਿ ਕਨਟੇਨਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ। Pods replace, reschedule ਅਤੇ scale ਹੁੰਦੇ ਹਨ—ਇਸ ਲਈ ਉਹਨਾਂ ਦੇ IPs ਅਤੇ ਮਸ਼ੀਨਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। Service ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਬਦਲ ਰਹੀ Pods ਦੀ ਸੈਟ ਲਈ ਇੱਕ ਸਥਿਰ "ਫਰੰਟ ਡੋਰ" ਦਿਓ।
Service ਤੁਹਾਨੂੰ ਇੱਕ ਲਗਾਤਾਰ ਵਰਚੁਅਲ IP ਅਤੇ DNS ਨਾਮ ਦਿੰਦੀ (ਜਿਵੇਂ payments)। ਉਸ ਨਾਮ ਦੇ ਪਿੱਛੇ, Kubernetes ਲਗਾਤਾਰ ਟrac='
Container orchestration ਉਹ ਆਟੋਮੇਸ਼ਨ ਹੈ ਜੋ ਮਸ਼ੀਨਾਂ ਫੇਲ ਹੋਣ, ਟ੍ਰੈਫਿਕ ਬਦਲਣ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟਾਂ ਹੋਣ ਵੇਲੇ ਐਪਸ ਨੂੰ ਚੱਲਦਾ ਰੱਖਦੀ ਹੈ। ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਸਿੰਭਾਲਦਾ ਹੈ:
Kubernetes ਨੇ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ infrastructure ਮਹੌਲਾਂ ਵਿੱਚ ਕਰਨ ਲਈ ਇੱਕ ਸਥਿਰ ਮਾਡਲ ਪ੍ਰਚਲਿਤ ਕੀਤਾ।
ਮੁੱਖ ਸਮੱਸਿਆ কਨਟੇਨਰ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਨਹੀਂ ਸੀ—ਇਹ ਸੀ ਕਿ ਸਹੀ ਕਨਟੇਨਰਾਂ ਨੂੰ ਸਹੀ ਆਕਾਰ ਵਿੱਚ ਲਗਾਤਾਰ ਚੱਲਦਾ ਰੱਖਣਾ। ਸਕੇਲ 'ਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਫੇਲਯੂਰਜ਼ ਅਤੇ ਡ੍ਰਿਫ਼ ਹੁੰਦੇ ਹਨ:
Kubernetes ਨੇ ਇੱਕ ਸਧਾਰਨ ਕੰਟਰੋਲ-ਪਲੇਨ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਦੇ ਕੇ ਆਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਦੁਹਰਾਯੋਗ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਇਆ।
ਡਿਕਲੇਰਟਿਵ ਸਿਸਟਮ ਵਿੱਚ ਤੁਸੀਂ ਉਸ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, “3 replicas ਚਲਾਓ”), ਅਤੇ ਸਿਸਟਮ ਲਗਾਤਾਰ ਹਕੀਕਤ ਨੂੰ ਉਸ ਨਤੀਜੇ ਨਾਲ ਮਿਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।
ਵਰਤੋਂ ਵਾਲੀ ਕਾਰਵਾਈ:
kubectl apply ਜਾਂ GitOps)ਇਸ ਨਾਲ "ਛੁਪੇ ਹੋਏ runbooks" ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਦਲਾਅ diffs ਵਜੋਂ ਰਿਵਿਊ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਐਡ-ਹੋਕ ਕਮਾਂਡਾਂ ਵਜੋਂ।
Controllers ਉਹ ਕੰਟਰੋਲ ਲੂਪ ਹਨ ਜੋ ਦੁਹਰਾਉਂਦੇ ਹਨ:
ਇਹ ਡਿਜ਼ਾਇਨ ਆਮ ਫੇਲਯੂਰਜ਼ ਨੂੰ ਖਾਸ-ਕੇਸ ਬਣਾਉਂਦੀ ਨਾਂ ਕਿ ਰੁਟੀਨ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਇਕ Pod ਕ੍ਰੈਸ਼ ਕਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨੋਡ ਗੁਆਂਢੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਸੰਬੰਧਿਤ controller ਸਿਰਫ਼ ਨੋਟਿਸ ਕਰੇਗਾ “ਸਾਡੇ ਕੋਲ ਚਾਹੀਦੇ replicas ਘੱਟ ਹਨ” ਅਤੇ ਨਵੇਂ ਬਣਾਇਆ ਜਾਵੇਗਾ।
Kubernetes individuele ਕਨਟੇਨਰਾਂ ਦੀ ਬਜਾਏ Pods ਨੂੰ ਸ਼ੈਡਿਊਲ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਵਰਕਲੋਡ ਛੋਟੇ, ਇੱਕ-ਦੂਜੇ ਨਾਲ ਗਹਿਰਾਈ ਨਾਲ ਜੁੜੇ ਪ੍ਰੋਸੈਸਾਂ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।
Pods ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ:
localhost ਉੱਤੇ ਗੱਲਬਾਤ)ਨਿਯਮ: Pods ਨੂੰ ਛੋਟਾ ਅਤੇ ਏਕਜੁੱਟ ਰੱਖੋ—ਉਹ ਹੀ ਕੰਟੇਨਰ ਇੱਕਠੇ ਰੱਖੋ ਜੋ ਲਾਈਫਸਾਇਕਲ, ਨੇਟਵਰਕ ਆਈਡੈਂਟੀਟੀ ਜਾਂ ਲੋਕਲ ਡੇਟਾ ਸਾਂਝਾ ਕਰਨੇ ਹਨ।
Labels ਸਧਾਰਨ key/value ਟੈਗ ਹਨ (ਉਦਾਹਰਨ: app=checkout, env=prod)। Selectors ਇਹਨਾਂ ਲੇਬਲਾਂ 'ਤੇ ਕਵੈਰੀ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕਿ ਗਰੁੱਪ ਬਣ ਸਕਣ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇੰਸਟੈਂਸ ਅਸਥਾਈ ਹੁੰਦੇ ਹਨ: Pods ਰੀਸਕੇਡਿਊਲ ਅਤੇ ਰੋਲਆਉਟ ਦੌਰਾਨ ਆਉਂ ਤੇ ਜਾਂਦੇ ਹਨ। labels/selectors ਨਾਲ, ਸੰਬੰਧ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ ("ਉਹ ਸਾਰੇ Pods ਜਿਨ੍ਹਾਂ 'ਤੇ ਇਹ ਲੇਬਲ ਹਨ") ਭਾਵੇਂ ਮੈਂਬਰ ਬਦਲਣ।
ਓਪਰੇਸ਼ਨਲ ਟਿਪ: ਇੱਕ ਛੋਟੀ ਲੇਬਲ ਟੈਕਸੋਨੋਮੀ (app, team, env, tier) ਸਥਾਪਿਤ ਕਰੋ ਅਤੇ ਨੀਤੀ ਨਾਲ ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਗੱਡ-ਬਣਜ ਨਾ ਹੋਵੇ।
Service ਇੱਕ ਸਥਿਰ ਵਰਚੁਅਲ IP ਅਤੇ DNS ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਬਦਲਦੀਆਂ Pods ਦੀ ਸੈਟ ਵੱਲ ਰੂਟ ਕਰਦਾ ਹੈ।
Service ਨੂੰ ਵਰਤੋ ਜਦੋਂ:
HTTP ਰਾਊਟਿੰਗ, TLS termination ਅਤੇ edge ਨੀਤੀਆਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ Services ਦੇ ਉੱਪਰ Ingress ਜਾਂ Gateway API ਵਰਤੇ ਜਾਂਦੇ ਹਨ।
Kubernetes API ਨੂੰ ਪ੍ਰਮੁੱਖ ਉਤਪਾਦ ਸਤਹ ਮੰਨਣ ਦਾ ਫੈਸਲਾ ਵੱਡਾ ਸੀ: ਹਰ ਚੀਜ਼ ਇੱਕ API ਆਬਜੈਕਟ ਹੈ (Deployments, Services, ConfigMaps, ਆਦਿ)। kubectl ਇੱਕ client ਹੈ।
ਵਾਹਲੇ ਲਾਭ:
ਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਪਲੇਟਫਾਰਮ ਬਣਾ ਰਹੇ ਹੋ, ਉਨ੍ਹਾਂ ਵਰਕਫਲੋਜ਼ ਨੂੰ API ਕਾਂਟ੍ਰੈਕਟਾਂ ਦੇ ਆਸਪਾਸ ਡਿਜ਼ਾਇਨ ਕਰੋ, ਕਿਸੇ ਵਿਸ਼ੇਸ਼ UI ਦੇ ਆਸਪਾਸ ਨਹੀਂ।
etcd ਕਨਟਰੋਲ ਪਲੇਨ ਦਾ ਡੇਟਾਬੇਸ ਹੈ—ਕਲੱਸਟਰ ਦੀ "ਸਰੋਤ-ਸੱਚ"। ਜਦੋਂ ਤੁਸੀਂ Deployment ਬਣਾਉਂਦੇ ਹੋ, ReplicaSet ਸਕੇਲ ਕਰਦੇ ਹੋ ਜਾਂ Service ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਚਾਹੀਦੀ ਸੰਰਚਨਾ etcd ਵਿੱਚ ਲਿਖੀ ਜਾਂਦੀ ਹੈ। Controllers ਅਤੇ ਹੋਰ ਕੰਟਰੋਲ-ਪਲੇਨ ਕੰਪੋਨੈਂਟ ਇਸ ਸਟੇਟ ਨੂੰ ਦੇਖਦੇ ਹਨ ਅਤੇ ਹਕੀਕਤ ਨੂੰ ਮਿਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
ਪ੍ਰਾਇਕਟਿਕਲ ਗਾਈਡਲਾਈਨ:
ਜੇ ਤੁਸੀਂ managed Kubernetes ਚਲਾ ਰਹੇ ਹੋ, ਆਪਣੇ ਪ੍ਰੋਵਾਇਡਰ ਤੋਂ ਪਤਾ ਕਰੋ ਕਿ ਉਹ ਕੀ ਬੈਕਅੱਪ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਚੀਜ਼ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਬੈਕਅੱਪ ਕਰਨੀ ਪਵੇਗੀ (ਜਿਵੇਂ persistent volumes ਅਤੇ ਐਪ ਡੇਟਾ)।
Kubernetes ਕੋਰ ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਫੀਚਰਾਂ ਨੂੰ ਵਾਧਾ ਕਰਨ ਲਈ extensibility ਮੁਹੱਈਆ ਕਰਵਾਉਂਦਾ ਹੈ:
ਇਸ ਨਾਲ "Kubernetes ਉੱਤੇ ਪਲੇਟਫਾਰਮ" ਬਣਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਖ਼ਤਰਾ tool-sprawl ਹੈ: ਬਹੁਤ ਸਾਰੇ CRDs, ਓਵਰਲੈਪਿੰਗ ਟੂਲ ਅਤੇ ਅਸਥਿਰ convention। ਅੰਕਲਣ ਲਈ ਪੁੱਛੋ: