Kubernetes Pod VPN ਬਨਾਮ ਈਗ੍ਰੈਸ ਗੇਟਵੇ: ਸੁਰੰਗ ਕਿਸਦੀ ਹੈ?
Pod ਆਪਣਾ ਖੁਦ ਦਾ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਹੈ, ਇਸ ਲਈ ਅਸਲ ਚੋਣ ਇਹ ਹੈ ਕਿ ਸੁਰੰਗ ਕਿਹੜੀ ਪਰਤ ਕੋਲ ਹੈ: ਹਰ ਵਰਕਲੋਡ ਲਈ ਪਛਾਣ ਜਾਂ ਇੱਕ ਸਾਂਝੇ ਸਰੋਤ ਵਾਲਾ CNI-ਨਿਰਦੇਸ਼ਿਤ ਈਗ੍ਰੈਸ।
ਤੁਸੀਂ vpn-gateway ਨਾਮ ਦਾ Pod ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਇੱਕ ਟੈਸਟ ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਦੇ ਪਤੇ ਵੱਲ ਭੇਜਦੇ ਹੋ ਅਤੇ ਪੈਕਟ ਗਾਇਬ ਹੁੰਦੇ ਦੇਖਦੇ ਹੋ। ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ ਅਤੇ kubelet ਕੋਲ ਕੋਈ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਹੈ। ਕਾਰਨ ਸੰਰਚਨਾਤਮਕ ਹੈ, ਕਨਫਿਗਰੇਸ਼ਨ ਸੰਬੰਧੀ ਨਹੀਂ: Kubernetes ਹਰ Pod ਨੂੰ ਆਪਣਾ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਨਾਮ, ਲੇਬਲ ਜਾਂ ਸਾਂਝਾ API ਨੇਮਸਪੇਸ ਪੈਕਟ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ ਇਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦੇ। ਇਸ ਲਈ VPN ਟ੍ਰੈਫਿਕ ਕਲਸਟਰ ਤੋਂ ਕਿਵੇਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰਨਾ ਮਾਲਕੀਅਤ ਦੇ ਸਵਾਲ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕੰਟੇਨਰ ਇਮੇਜ ਤੋਂ ਨਹੀਂ।
ਦੋ ਵਿਧੀਆਂ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਤੈਨਾਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਆਪਸ ਵਿੱਚ ਬਦਲਣਯੋਗ ਨਹੀਂ ਹਨ। ਇੱਕ ਸੁਰੰਗ ਨੂੰ ਵਰਕਲੋਡ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਰੱਖਦੀ ਹੈ। ਦੂਜੀ CNI ਨੂੰ ਕਹਿੰਦੀ ਹੈ ਕਿ ਚੁਣੇ ਗਏ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਿਰਧਾਰਿਤ ਗੇਟਵੇ ਨੋਡ ਰਾਹੀਂ ਲੰਘਾਏ। ਉਹ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ, ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸਕੇਲ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਖਰੀਆਂ ਟੀਮਾਂ ਪ੍ਰਤੀ ਜਵਾਬਦੇਹ ਹਨ, ਇਸ ਲਈ ਕੰਟੇਨਰ ਦਾ ਸਵਾਲ ਆਮ ਤੌਰ ’ਤੇ ਅਜਿਹੀ ਬਹਿਸ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਕਦੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ।
Pod ਦੀ ਸੀਮਾ ਨੇਮਸਪੇਸ ਹੈ, ਜੰਪ ਹੋਸਟ ਨਹੀਂ
Linux ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਆਪਣੇ ਇੰਟਰਫੇਸ, ਪਤੇ, ਰੂਟ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਰ Pod ਨੂੰ ਇੱਕ ਮਿਲਦਾ ਹੈ। ਉਸ Pod ਵਿੱਚਲੇ ਕੰਟੇਨਰ ਉਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਲਈ ਸਹਾਇਕ ਕੰਟੇਨਰ ਅਜਿਹੇ ਰੂਟ ਮੁੜ ਲਿਖ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। ਨਾਲ ਵਾਲੇ Pod ਕੋਲ ਦਿਖਣ ਵਿੱਚ ਸਮਾਨ ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਸਟੈਕ ਹੁੰਦਾ ਹੈ। ਗੇਟਵੇ Pod ਦੇ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਯੋਗ ਕੋਈ ਸਾਂਝੀ ਟੇਬਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਇੱਕ ਨੇਮਸਪੇਸ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਦਾ ਕੋਈ ਅਸਿੱਧਾ ਹਸਤਾਂਤਰਣ ਨਹੀਂ ਹੈ।
ਇਸੇ ਲਈ ਗੇਟਵੇ-Pod ਪੈਟਰਨ ਤਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉੱਪਰੋਂ ਕੁਝ ਸੱਚਮੁੱਚ ਉਸ ਨੂੰ ਪੈਕਟ ਭੇਜਦਾ ਹੈ: ਇੱਕ Service, ਨੋਡ ’ਤੇ ਸਥਿਰ ਰੂਟ ਜਾਂ CNI ਵਿੱਚ ਸਟੀਅਰਿੰਗ ਨੀਤੀ। ਸਿਰਫ਼ ਪਤਾ ਕੁਝ ਵੀ ਨਹੀਂ ਖਿੱਚਦਾ।
ਹਰ Pod ਲਈ ਸੁਰੰਗ ਕੀ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੀ ਕੀਮਤ ਪੈਂਦੀ ਹੈ
ਵਰਕਲੋਡ ਦੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਸੁਰੰਗ ਉਸ ਵਰਕਲੋਡ ਨੂੰ ਆਪਣੀ ਕਲਾਇੰਟ ਪਛਾਣ ਦਿੰਦੀ ਹੈ, ਜੋ ਕਈ ਰਿਮੋਟ-ਐਕਸੈਸ ਸੇਵਾਵਾਂ ਸੈਸ਼ਨ ਨੂੰ ਅਧਿਕਾਰਤ ਜਾਂ ਹਿਸਾਬ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੰਗਦੀਆਂ ਹਨ। ਨੁਕਸਾਨ ਦਾ ਘੇਰਾ ਵੀ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ: ਟੁੱਟੀ ਸੁਰੰਗ ਸਭ ਕੁਝ ਵਰਤਦੇ ਸਾਂਝੇ ਰਾਹ ਦੀ ਥਾਂ ਇੱਕ Deployment ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹ ਕਿਵੇਂ ਚੱਲਦੀ ਹੈ ਇਹ ਲਾਗੂਆਣ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਹੀ ਲੋਕ ਗਲਤ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦੇ ਹਨ।
ਜਿਸ ਸੈਟਅਪ ਨੂੰ ਸਿਰਫ਼ ਕਰਨਲ ਸਥਿਤੀ ਚਾਹੀਦੀ ਹੈ ਉਹ init ਕੰਟੇਨਰ ਵਿੱਚ ਪੂਰਾ ਹੋ ਕੇ ਬਾਹਰ ਨਿਕਲ ਸਕਦਾ ਹੈ। ਜਿਸ ਯੂਜ਼ਰਸਪੇਸ ਡੈਮਨ ਨੂੰ Pod ਦੀ ਪੂਰੀ ਉਮਰ ਜੀਵਿਤ ਰਹਿਣਾ ਹੈ ਉਸ ਨੂੰ Kubernetes 1.29 ਵਿੱਚ ਨੇਟਿਵ ਸਾਈਡਕਾਰ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਮੁੜ-ਸ਼ੁਰੂ ਹੋਣਯੋਗ init ਕੰਟੇਨਰ ਰੂਪ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਸਵਾਦ ਤੋਂ ਨਹੀਂ, ਸੁਰੰਗ ਦੇ ਲਾਗੂਆਣ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਇਸ ਮਾਡਲ ਦੀ ਕੀਮਤ ਦੁਹਰਾਅ ਹੈ: ਹਰ ਰੈਪਲਿਕਾ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ, ਆਪਣਾ ਸੁਰੰਗ ਪਤਾ ਲੈਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਰਿਮੋਟ ਸੈਸ਼ਨ ਸਲਾਟ ਵਰਤਦੀ ਹੈ, ਇਸ ਲਈ ਆਟੋਸਕੇਲਿੰਗ ਘਟਨਾ ਲਿੰਕ ਦੇ ਦੂਜੇ ਪਾਸੇ ਸਮਰੱਥਾ ਘਟਨਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਸਾਰੀਆਂ ਰੈਪਲਿਕਾਵਾਂ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਉਹ ਕੀਮਤ ਨਹੀਂ ਹਟਾਉਂਦਾ, ਇਹ ਆਡਿਟ ਟ੍ਰੇਲ ਹਟਾਉਂਦਾ ਹੈ। ਸਮਰੱਥਾਵਾਂ ਵੀ ਉਸੇ ਜਾਂਚ ਦੀ ਹੱਕਦਾਰ ਹਨ, ਕਿਉਂਕਿ ਆਪਣੇ ਨੇਮਸਪੇਸ ਵਿੱਚ NET_ADMIN ਚਾਹੁਣ ਵਾਲੀ ਸੁਰੰਗ ਕੋਲ privileged: true ਉਦਾਹਰਨ ਦੇ ਪੂਰੇ ਹੋਸਟ ਦਾ ਅਧਿਕਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ।
ਜਦੋਂ CNI ਈਗ੍ਰੈਸ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ
ਜੇ CNI ਇਸ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਈਗ੍ਰੈਸ ਗੇਟਵੇ ਵਰਕਲੋਡ ਅਤੇ ਮੰਜ਼ਿਲ ਸੀਮਾ ਅਨੁਸਾਰ ਟ੍ਰੈਫਿਕ ਚੁਣਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਅਨੁਮਾਨਯੋਗ ਸਰੋਤ ਪਤੇ ਹੇਠ ਚੁਣੇ ਨੋਡਾਂ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ। Cilium ਦਾ ਸੰਸਕਰਣ ਆਮ ਹਵਾਲਾ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਦਸਤਾਵੇਜ਼ ਸਾਫ਼ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਖਾਸ Cilium ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਸਹੀ ਇੰਟਰਫੇਸ ਤੇ ਪਤਿਆਂ ਵਾਲੇ ਗੇਟਵੇ ਨੋਡ ਚਾਹੀਦੇ ਹਨ। ਇਹ Pod ਬਣਨ ਤੋਂ ਬਾਅਦ ਦੀ ਸ਼ੁਰੂਆਤੀ ਅਵਧੀ ਵੀ ਦੱਸਦਾ ਹੈ ਜਦੋਂ ਸਟੀਅਰਿੰਗ ਅਜੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ, ਜੋ ਪੈਰ-ਟਿੱਪਣੀ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਇਨਪੁਟ ਹੈ।
ਉਸ ਦੇਰੀ ਨੂੰ ਆਪਣੇ ਵਾਅਦੇ ਦੇ ਸਾਹਮਣੇ ਪੜ੍ਹੋ। ਜੇ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਕੋਈ ਵੀ ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਹੋਰ ਰਾਹ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਤਾਂ ਖੱਡ ਦੌਰਾਨ ਭੇਜਣ ਵਾਲਾ ਨਵਾਂ Pod ਇਸ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਤੋੜ ਚੁੱਕਾ ਹੈ, ਇਸ ਲਈ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ: ਨੀਤੀ ਲਾਗੂ ਹੋਣ ਤੱਕ ਐਪਲੀਕੇਸ਼ਨ ਰੋਕੋ, ਜਾਂ ਖਿੜਕੀ ਸਵੀਕਾਰ ਕਰੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਦਾਅਵੇ ਨੂੰ ਤੰਗ ਰੱਖੋ। ਈਗ੍ਰੈਸ ਗੇਟਵੇ ਰਾਹ ਚੁਣਦਾ ਹੈ ਅਤੇ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਇਹ VPN ਖਤਮ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਪਿੱਛੇ ਸਮਰਥਿਤ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਕਲਸਟਰ ਨੂੰ ਤੁਹਾਡੇ ਰਿਮੋਟ ਨੈੱਟਵਰਕ ਦਾ ਕਲਾਇੰਟ ਨਹੀਂ ਬਣਾਉਂਦਾ।
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
ਅਨੁਵਾਦ ਚੁੱਪਚਾਪ ਬਦਲਦਾ ਹੈ ਕਿ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਕੀ ਦੇਖਦਾ ਹੈ
ਗੇਟਵੇ ਵੱਲੋਂ ਸਰੋਤ ਮੁੜ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਹਰ Pod ਦੇ ਪਤੇ ਚਲੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਪਛਾਣ ’ਤੇ ਅਧਾਰਿਤ ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਇੱਕ ਸਾਂਝੇ ਪਤੇ ’ਤੇ ਅਧਾਰਿਤ ਸੂਚੀ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹ ਖਾਮੀ ਨਹੀਂ, ਵਟਾਂਦਰਾ ਹੈ: ਸੰਭਾਲ ਲਈ ਘੱਟ ਨਿਯਮ, ਕੁਝ ਗਲਤ ਵਿਵਹਾਰ ਕਰੇ ਤਾਂ ਮੋਟਾ ਆਰੋਪਣ।
ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਬੇਨਤੀ ਲੌਗਿੰਗ ਨੂੰ ਉਹ ਚੁੱਕਣਾ ਪਵੇਗਾ ਜੋ ਨੈੱਟਵਰਕ ਹੁਣ ਰਿਪੋਰਟ ਨਹੀਂ ਕਰਦਾ। ਗੇਟਵੇ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਬਦਲੀ ਨੂੰ ਸਾਂਝਾ ਢਾਂਚਾ ਮੰਨੋ, ਕਿਉਂਕਿ ਇੱਕ ਨੋਡ ਦਾ ਰੀਬੂਟ ਹੁਣ ਉਸ ਪਿੱਛੇ ਦੇ ਹਰ ਵਰਕਲੋਡ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਜਲਦੀ ਜਾਂਚੋ: ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਨੂੰ ਅਨੁਵਾਦਿਤ ਪਤੇ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤਰੀਕਾ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ ਇੱਕ ਰੂਟ ਜਾਂ NAT ਰਾਹੀਂ ਜਿਸ ਦਾ ਮਾਲਕ ਇਨਸਾਨ ਹੋਵੇ, ਮੈਨੀਫੈਸਟ ਨਹੀਂ। ਪਤਾ ਯੋਜਨਾ ਵੀ ਇੱਥੇ ਆਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਓਵਰਲੈਪ ਕਰਦੀਆਂ ਕਲਸਟਰ ਅਤੇ ਰਿਮੋਟ ਸੀਮਾਵਾਂ ਦੋਵੇਂ ਮਾਡਲ ਤੋੜਦੀਆਂ ਹਨ ਅਤੇ IPv6 ਅਪਣਾਉਣਾ ਵਿਰੋਧਾਭਾਸੀ ਯੋਜਨਾ ਦਾ ਬਹਾਨਾ ਨਹੀਂ ਹੈ।
ਮਾਲਕੀਅਤ ਨਾਲ ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਵਾਅਦਾ ਕੀਤੀ ਅਸਫਲਤਾ ਜਾਂਚੋ
ਹਰ Pod ਲਈ ਸੁਰੰਗ ਤਦੋਂ ਚੁਣੋ ਜਦੋਂ ਰਿਮੋਟ ਸੇਵਾ ਵੱਖਰੇ ਵਰਕਲੋਡ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਸਿਰਫ਼ ਕੁਝ Deployment ਨੂੰ ਲਿੰਕ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਅਸਫਲਤਾ ਸਥਾਨਕ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਗੇਟਵੇ ਤਦੋਂ ਚੁਣੋ ਜਦੋਂ ਨੈੱਟਵਰਕ ਟੀਮ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਰਾਹ ਹੈ, ਜਦੋਂ ਕਈ ਵਰਕਲੋਡ ਇੱਕ ਮੰਜ਼ਿਲ ਸਾਂਝੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਸਥਿਰ ਸਰੋਤ ਪਤਾ ਹੀ ਪੂਰੀ ਕਸਰਤ ਦਾ ਮਕਸਦ ਹੈ।
ਕਿਵੇਂ ਵੀ ਹੋਵੇ, ਸਥਿਰ ਸਥਿਤੀ ਨਹੀਂ, ਤੁਸੀਂ ਵੇਚਿਆ ਗੁਣ ਜਾਂਚੋ। ਇੱਕ Pod ਬਣਾਓ, ਉਸ ਨੂੰ ਤੁਰੰਤ ਭੇਜਣ ਦਿਓ, ਅਤੇ ਜੇ ਵਾਅਦਾ ਸੀ ਕਿ ਸੁਰੰਗ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਬਚਦਾ ਤਾਂ ਪਹਿਲੇ ਕੁਝ ਸਕਿੰਟ ਦੇਖੋ। ਪੰਜ ਰੈਪਲਿਕਾਵਾਂ ਤੱਕ ਸਕੇਲ ਕਰੋ ਅਤੇ ਜੇ ਵਾਅਦਾ ਹਰ ਵਰਕਲੋਡ ਲਈ ਪਛਾਣ ਸੀ ਤਾਂ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਜਿਹੜੇ ਸੈਸ਼ਨ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਉਹ ਗਿਣੋ। ਇਹ ਦੋ ਜਾਂਚਾਂ ਮੈਨੀਫੈਸਟ ਦੀ ਸਮੀਖਿਆ ਨਾਲੋਂ ਕਿਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਧੀ ਦੀਆਂ ਹੱਦਾਂ ਉਜਾਗਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਅਗਲੀ ਘਟਨਾ ਕਿਸ ਟੀਮ ਦੀ ਹੈ।