“ਕੁਬਰਨੇਟਸ ਨੇ ਲੇਟੈਂਸੀ ਨੂੰ 10 ਗੁਣਾ ਵਧਾਇਆ”: ਇਸ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ?

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

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

ਕੁਝ ਹਫ਼ਤੇ ਪਹਿਲਾਂ, ਮੇਰੀ ਟੀਮ ਇੱਕ ਸਿੰਗਲ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਇੱਕ ਕੋਰ ਪਲੇਟਫਾਰਮ 'ਤੇ ਮਾਈਗ੍ਰੇਟ ਕਰ ਰਹੀ ਸੀ ਜਿਸ ਵਿੱਚ CI/CD, ਇੱਕ Kubernetes-ਅਧਾਰਿਤ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਹੋਰ ਉਪਯੋਗੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਸਨ। ਇਹ ਇੱਕ ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟ ਸੀ: ਅਸੀਂ ਇਸ 'ਤੇ ਨਿਰਮਾਣ ਕਰਨ ਅਤੇ ਆਉਣ ਵਾਲੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਲਗਭਗ 150 ਹੋਰ ਸੇਵਾਵਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਸੀ। ਇਹ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਸਪੇਨ ਦੇ ਕੁਝ ਸਭ ਤੋਂ ਵੱਡੇ ਔਨਲਾਈਨ ਬਾਜ਼ਾਰਾਂ (Infojobs, Fotocasa, ਅਤੇ ਹੋਰ) ਨੂੰ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।

ਜਦੋਂ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੁਬਰਨੇਟਸ 'ਤੇ ਤੈਨਾਤ ਕੀਤਾ ਅਤੇ ਕੁਝ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਸ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਚਿੰਤਾਜਨਕ ਹੈਰਾਨੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ। ਲੇਟੈਂਸੀ (ਲੇਟੈਂਸੀ) ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ EC2 ਨਾਲੋਂ 10 ਗੁਣਾ ਵੱਧ ਸੀ। ਅੰਤ ਵਿੱਚ, ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਲੱਭਣਾ ਜਾਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਮਾਈਗ੍ਰੇਸ਼ਨ (ਅਤੇ, ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ, ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ) ਨੂੰ ਛੱਡਣਾ ਜ਼ਰੂਰੀ ਸੀ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ EC2 ਦੇ ਮੁਕਾਬਲੇ ਲੇਟੈਂਸੀ ਇੰਨੀ ਜ਼ਿਆਦਾ ਕਿਉਂ ਹੈ?

ਰੁਕਾਵਟ ਲੱਭਣ ਲਈ, ਅਸੀਂ ਪੂਰੇ ਬੇਨਤੀ ਮਾਰਗ ਦੇ ਨਾਲ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠੇ ਕੀਤੇ। ਸਾਡਾ ਆਰਕੀਟੈਕਚਰ ਸਧਾਰਨ ਹੈ: ਇੱਕ API ਗੇਟਵੇ (Zuul) EC2 ਜਾਂ Kubernetes ਵਿੱਚ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਉਦਾਹਰਣਾਂ ਲਈ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਦਾ ਹੈ। Kubernetes ਵਿੱਚ, ਅਸੀਂ ਇੱਕ NGINX ਇੰਗ੍ਰੇਸ ਕੰਟਰੋਲਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਬੈਕਐਂਡ ਇਸ ਕਿਸਮ ਦੇ ਨਿਯਮਤ ਵਸਤੂਆਂ ਹਨ। ਡਿਪਲੋਮੇਟ ਸਪਰਿੰਗ ਪਲੇਟਫਾਰਮ 'ਤੇ ਇੱਕ JVM ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ।

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

ਇਹ ਮੁੱਦਾ ਬੈਕਐਂਡ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਲੇਟੈਂਸੀ ਨਾਲ ਸਬੰਧਤ ਜਾਪਦਾ ਸੀ (ਮੈਂ ਗ੍ਰਾਫ 'ਤੇ ਸਮੱਸਿਆ ਵਾਲੇ ਖੇਤਰ ਨੂੰ "xx" ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਹੈ)। EC2 ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਜਵਾਬ ਵਿੱਚ ਲਗਭਗ 20 ms ਲੱਗੇ। Kubernetes ਵਿੱਚ, ਲੇਟੈਂਸੀ 100-200 ms ਤੱਕ ਵਧ ਗਈ।

ਅਸੀਂ ਰਨਟਾਈਮ ਤਬਦੀਲੀ ਨਾਲ ਸਬੰਧਤ ਸੰਭਾਵਿਤ ਸ਼ੱਕੀਆਂ ਨੂੰ ਜਲਦੀ ਹੀ ਰੱਦ ਕਰ ਦਿੱਤਾ। JVM ਸੰਸਕਰਣ ਉਹੀ ਰਿਹਾ। ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਮੁੱਦੇ ਵੀ ਅਸੰਬੰਧਿਤ ਸਨ: ਐਪਲੀਕੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ EC2 ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਸਫਲਤਾਪੂਰਵਕ ਚੱਲ ਰਹੀ ਸੀ। ਲੋਡ? ਪਰ ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਵੀ ਉੱਚ ਲੇਟੈਂਸੀ ਦੇਖੀ। ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਦੇ ਵਿਰਾਮ ਵੀ ਨਾ-ਮਾਤਰ ਸਨ।

ਸਾਡੇ ਇੱਕ Kubernetes ਐਡਮਿਨ ਨੇ ਪੁੱਛਿਆ ਕਿ ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕੋਈ ਬਾਹਰੀ ਨਿਰਭਰਤਾ ਹੈ, ਕਿਉਂਕਿ DNS ਪੁੱਛਗਿੱਛਾਂ ਨੇ ਪਹਿਲਾਂ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੀਆਂ ਸਨ।

ਪਰਿਕਲਪਨਾ 1: DNS ਨਾਮ ਰੈਜ਼ੋਲਿਊਸ਼ਨ

ਹਰੇਕ ਬੇਨਤੀ ਲਈ, ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਡੋਮੇਨ ਵਿੱਚ ਇੱਕ AWS Elasticsearch ਉਦਾਹਰਣ ਨੂੰ ਇੱਕ ਤੋਂ ਤਿੰਨ ਕਾਲਾਂ ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਕਿ elastic.spain.adevinta.comਸਾਡੇ ਕੋਲ ਮੌਜੂਦ ਡੱਬਿਆਂ ਦੇ ਅੰਦਰ ਇੱਕ ਖੋਲ ਹੈ।, ਤਾਂ ਜੋ ਅਸੀਂ ਜਾਂਚ ਕਰ ਸਕੀਏ ਕਿ ਕੀ ਡੋਮੇਨ ਖੋਜ ਸੱਚਮੁੱਚ ਬਹੁਤ ਸਮਾਂ ਲੈਂਦੀ ਹੈ।

ਕੰਟੇਨਰ ਤੋਂ DNS ਪੁੱਛਗਿੱਛਾਂ:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਣ ਵਾਲੇ EC2 ਉਦਾਹਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਮਿਲਦੀਆਂ-ਜੁਲਦੀਆਂ ਬੇਨਤੀਆਂ:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

ਇਹ ਦੇਖਦੇ ਹੋਏ ਕਿ ਲੁੱਕਅੱਪ ਵਿੱਚ ਲਗਭਗ 30 ਮਿਲੀਮੀਟਰ ਲੱਗਦੇ ਹਨ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਇਲਾਸਟਿਕਸਚ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਵੇਲੇ DNS ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਅਸਲ ਵਿੱਚ ਵਧੀ ਹੋਈ ਲੇਟੈਂਸੀ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾ ਰਿਹਾ ਸੀ।

ਹਾਲਾਂਕਿ, ਇਹ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਅਜੀਬ ਸੀ:

1. ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਕੁਬਰਨੇਟਸ ਐਪਲੀਕੇਸ਼ਨ ਹਨ ਜੋ AWS ਸਰੋਤਾਂ ਨਾਲ ਬਿਨਾਂ ਕਿਸੇ ਮਹੱਤਵਪੂਰਨ ਲੇਟੈਂਸੀ ਦੇ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ। ਕਾਰਨ ਜੋ ਵੀ ਹੋਵੇ, ਇਹ ਇਸ ਖਾਸ ਮਾਮਲੇ ਲਈ ਖਾਸ ਹੈ।
2. ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ JVM ਇਨ-ਮੈਮੋਰੀ DNS ਕੈਸ਼ਿੰਗ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਚਿੱਤਰਾਂ ਵਿੱਚ, TTL ਮੁੱਲ ਨੂੰ ਹਾਰਡਕੋਡ ਕੀਤਾ ਗਿਆ ਹੈ $JAVA_HOME/jre/lib/security/java.security ਅਤੇ 10 ਸਕਿੰਟਾਂ 'ਤੇ ਸੈੱਟ ਕਰੋ: networkaddress.cache.ttl = 10ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, JVM ਨੂੰ ਸਾਰੀਆਂ DNS ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ 10 ਸਕਿੰਟਾਂ ਲਈ ਕੈਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਪਹਿਲੀ ਪਰਿਕਲਪਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਅਸੀਂ DNS ਲੁੱਕਅੱਪ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕਰਨ ਅਤੇ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕੀ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਜਾਵੇਗੀ। ਪਹਿਲਾਂ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਸਦੇ ਡੋਮੇਨ ਨਾਮ ਦੀ ਬਜਾਏ ਇਸਦੇ IP ਪਤੇ ਰਾਹੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ Elasticsearch ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਲਈ ਮੁੜ ਸੰਰਚਿਤ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ। ਇਸ ਲਈ ਇੱਕ ਕੋਡ ਤਬਦੀਲੀ ਅਤੇ ਇੱਕ ਨਵੀਂ ਤੈਨਾਤੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਇਸ ਲਈ ਅਸੀਂ ਡੋਮੇਨ ਨੂੰ ਇਸਦੇ IP ਪਤੇ ਨਾਲ ਮੈਪ ਕੀਤਾ ਹੈ। /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

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

ਨੈੱਟਵਰਕ ਡਾਇਗਨੌਸਟਿਕਸ

ਅਸੀਂ ਕੰਟੇਨਰ ਤੋਂ ਆਵਾਜਾਈ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ tcpdumpਨੈੱਟਵਰਕ 'ਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਇਸਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

ਫਿਰ ਅਸੀਂ ਕੁਝ ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਕੈਪਚਰ ਨੂੰ ਡਾਊਨਲੋਡ ਕੀਤਾ (kubectl cp my-service:/capture.pcap capture.pcap) ਵਿੱਚ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਵਰਅਰਹਾਰਕ.

DNS ਪੁੱਛਗਿੱਛਾਂ ਬਾਰੇ ਕੁਝ ਵੀ ਸ਼ੱਕੀ ਨਹੀਂ ਸੀ (ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਜਾਣਕਾਰੀ ਨੂੰ ਛੱਡ ਕੇ ਜਿਸ ਬਾਰੇ ਮੈਂ ਬਾਅਦ ਵਿੱਚ ਚਰਚਾ ਕਰਾਂਗਾ)। ਹਾਲਾਂਕਿ, ਸਾਡੀ ਸੇਵਾ ਨੇ ਹਰੇਕ ਬੇਨਤੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ, ਇਸ ਵਿੱਚ ਕੁਝ ਅਜੀਬ ਗੱਲਾਂ ਸਨ। ਹੇਠਾਂ ਇੱਕ ਕੈਪਚਰ ਦਾ ਸਕ੍ਰੀਨਸ਼ੌਟ ਹੈ ਜੋ ਜਵਾਬ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਣ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

ਪੈਕੇਟ ਨੰਬਰ ਪਹਿਲੇ ਕਾਲਮ ਵਿੱਚ ਦਿਖਾਏ ਗਏ ਹਨ। ਸਪਸ਼ਟਤਾ ਲਈ, ਮੈਂ ਵੱਖ-ਵੱਖ TCP ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਰੰਗ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤਾ ਹੈ।

ਪੈਕੇਟ 328 ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਹਰੀ ਧਾਰਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਕਲਾਇੰਟ (172.17.22.150) ਨੇ ਕੰਟੇਨਰ (172.17.36.147) ਨਾਲ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕੀਤਾ। ਸ਼ੁਰੂਆਤੀ ਹੈਂਡਸ਼ੇਕ (328-330) ਤੋਂ ਬਾਅਦ, ਪੈਕੇਟ 331 ਲਿਆਇਆ HTTP GET /v1/.. — ਸਾਡੀ ਸੇਵਾ ਲਈ ਇੱਕ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ। ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ 1 ਮਿੰਟ ਲੱਗੇ।

ਸਲੇਟੀ ਸਟ੍ਰੀਮ (ਪੈਕੇਟ 339 ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ) ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਸਾਡੀ ਸੇਵਾ ਨੇ Elasticsearch ਉਦਾਹਰਣ ਨੂੰ ਇੱਕ HTTP ਬੇਨਤੀ ਭੇਜੀ ਹੈ (ਕੋਈ TCP ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ)। ਇਸ ਵਿੱਚ 18 ms ਲੱਗੇ।

ਹੁਣ ਤੱਕ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਅਤੇ ਸਮਾਂ ਲਗਭਗ ਅਨੁਮਾਨਿਤ ਦੇਰੀ (ਕਲਾਇੰਟ ਤੋਂ ਮਾਪਣ 'ਤੇ 20-30 ms) ਦੇ ਅਨੁਸਾਰ ਹੈ।

ਹਾਲਾਂਕਿ, ਨੀਲਾ ਭਾਗ 86 ms ਲੈਂਦਾ ਹੈ। ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ? ਪੈਕੇਟ 333 ਦੇ ਨਾਲ, ਸਾਡੀ ਸੇਵਾ ਨੇ ਇੱਕ HTTP GET ਬੇਨਤੀ ਭੇਜੀ /latest/meta-data/iam/security-credentials, ਅਤੇ ਇਸਦੇ ਤੁਰੰਤ ਬਾਅਦ, ਉਸੇ TCP ਕਨੈਕਸ਼ਨ ਉੱਤੇ, ਇੱਕ ਹੋਰ GET ਬੇਨਤੀ /latest/meta-data/iam/security-credentials/arn:...

ਅਸੀਂ ਪਾਇਆ ਕਿ ਇਹ ਟਰੇਸ ਦੌਰਾਨ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਅਨੁਕੂਲ ਸੀ। ਸਾਡੇ ਕੰਟੇਨਰਾਂ ਵਿੱਚ DNS ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਸੱਚਮੁੱਚ ਥੋੜ੍ਹਾ ਹੌਲੀ ਸੀ (ਇਸ ਵਰਤਾਰੇ ਦੀ ਵਿਆਖਿਆ ਕਾਫ਼ੀ ਦਿਲਚਸਪ ਹੈ, ਪਰ ਮੈਂ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਲਈ ਸੁਰੱਖਿਅਤ ਕਰਾਂਗਾ)। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਵੱਡੀ ਲੇਟੈਂਸੀ ਹਰੇਕ ਬੇਨਤੀ ਲਈ AWS ਇੰਸਟੈਂਸ ਮੈਟਾਡੇਟਾ ਸੇਵਾ ਨੂੰ ਕਾਲਾਂ ਕਾਰਨ ਹੋਈ ਸੀ।

ਪਰਿਕਲਪਨਾ 2: AWS ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਾਲਾਂ

ਦੋਵੇਂ ਅੰਤਮ ਬਿੰਦੂ ਸੰਬੰਧਿਤ ਹਨ AWS ਇੰਸਟੈਂਸ ਮੈਟਾਡੇਟਾ APIਸਾਡੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਇਲਾਸਟਿਕਸਚ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਕਾਲਾਂ ਮੁੱਢਲੀ ਅਧਿਕਾਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹਨ। ਸ਼ੁਰੂਆਤੀ ਬੇਨਤੀ ਦੌਰਾਨ ਐਕਸੈਸ ਕੀਤਾ ਗਿਆ ਐਂਡਪੁਆਇੰਟ ਉਦਾਹਰਣ ਨਾਲ ਸੰਬੰਧਿਤ IAM ਭੂਮਿਕਾ ਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹੈ।

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

ਦੂਜੀ ਬੇਨਤੀ ਇਸ ਉਦਾਹਰਣ ਲਈ ਅਸਥਾਈ ਅਨੁਮਤੀਆਂ ਲਈ ਦੂਜੇ ਅੰਤਮ ਬਿੰਦੂ ਨਾਲ ਸੰਪਰਕ ਕਰਦੀ ਹੈ:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

ਕਲਾਇੰਟ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਨਵੇਂ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨੇ ਪੈਂਦੇ ਹਨ (ਜਦੋਂ ਤੱਕ ਉਹਨਾਂ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਤਾਰੀਖ ਨਹੀਂ ਹੁੰਦੀ)। Expiration). ਮਾਡਲ ਸਧਾਰਨ ਹੈ: AWS ਸੁਰੱਖਿਆ ਕਾਰਨਾਂ ਕਰਕੇ ਅਕਸਰ ਅਸਥਾਈ ਕੁੰਜੀਆਂ ਨੂੰ ਘੁੰਮਾਉਂਦਾ ਹੈ, ਪਰ ਗਾਹਕ ਨਵੇਂ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਨਾਲ ਜੁੜੇ ਪ੍ਰਦਰਸ਼ਨ ਜੁਰਮਾਨੇ ਨੂੰ ਆਫਸੈੱਟ ਕਰਨ ਲਈ ਕੁਝ ਮਿੰਟਾਂ ਲਈ ਉਹਨਾਂ ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ।

AWS Java SDK ਨੂੰ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ।

GitHub 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਦੀ ਖੋਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਆਈ। #1921ਉਸਨੇ ਸਾਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਕਿ ਹੋਰ ਖੁਦਾਈ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਕਰਨੀ ਹੈ।

AWS SDK ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਨਵਿਆਉਂਦਾ ਹੈ ਜਦੋਂ ਹੇਠ ਲਿਖੀਆਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਸਥਿਤੀ ਹੁੰਦੀ ਹੈ:

• ਉਹਨਾਂ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਤਾਰੀਖ (Expiration) ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ EXPIRATION_THRESHOLD, 15 ਮਿੰਟਾਂ ਤੱਕ ਹਾਰਡ-ਕੋਡ ਕੀਤਾ ਗਿਆ।
• ਸਰਟੀਫਿਕੇਟ ਰੀਨਿਊ ਕਰਨ ਦੀ ਆਖਰੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਹੁਣ ਤੱਕ ਇਸ ਤੋਂ ਵੱਧ ਸਮਾਂ ਹੋ ਗਿਆ ਹੈ REFRESH_THRESHOLD, 60 ਮਿੰਟਾਂ ਲਈ ਹਾਰਡਕੋਡ ਕੀਤਾ ਗਿਆ।

ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਹੋ ਰਹੇ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਅਸਲ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਤਾਰੀਖ ਦੇਖਣ ਲਈ, ਅਸੀਂ ਕੰਟੇਨਰ ਅਤੇ EC2 ਉਦਾਹਰਣ ਦੋਵਾਂ ਤੋਂ ਉਪਰੋਕਤ cURL ਕਮਾਂਡਾਂ ਚਲਾਈਆਂ। ਕੰਟੇਨਰ ਤੋਂ ਪ੍ਰਾਪਤ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਤਾਰੀਖ ਬਹੁਤ ਛੋਟੀ ਸੀ: ਬਿਲਕੁਲ 15 ਮਿੰਟ।

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

ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਵੈਧਤਾ ਦੀ ਮਿਆਦ ਕਿਉਂ ਘੱਟ ਗਈ ਹੈ?

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

KIAM ਪੌਡਾਂ ਨੂੰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਸਮਝਦਾਰੀ ਦੀ ਗੱਲ ਹੈ ਕਿਉਂਕਿ ਔਸਤ ਪੌਡ ਜੀਵਨ ਕਾਲ EC2 ਉਦਾਹਰਣ ਨਾਲੋਂ ਛੋਟਾ ਹੁੰਦਾ ਹੈ। ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ, ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਉਹੀ 15 ਮਿੰਟ ਦੇ ਬਰਾਬਰ ਹੈ.

ਅੰਤ ਵਿੱਚ, ਇਹਨਾਂ ਦੋਨਾਂ ਡਿਫਾਲਟਾਂ ਨੂੰ ਜੋੜਨਾ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਹਰ ਸਰਟੀਫਿਕੇਟ 15 ਮਿੰਟਾਂ ਬਾਅਦ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। AWS Java SDK ਕਿਸੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਵੀਨੀਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਮਿਆਦ ਪੁੱਗਣ ਤੱਕ 15 ਮਿੰਟਾਂ ਤੋਂ ਘੱਟ ਸਮਾਂ ਬਾਕੀ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਅਸਥਾਈ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਨਵਿਆਉਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ AWS API ਨੂੰ ਕਈ ਕਾਲਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੁੰਦਾ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ AWS Java SDK ਵਿੱਚ ਖੋਜਿਆ ਹੈ। ਫੀਚਰ ਲਈ ਬੇਨਤੀ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਮਾਨ ਸਮੱਸਿਆ ਦਾ ਜ਼ਿਕਰ ਹੈ।

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

ਸਿੱਟਾ

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

ਅਸੀਂ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਪਹਿਲਾਂ ਕਦੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਇਆ, ਇਹ ਉਮੀਦ ਕਰਦੇ ਹੋਏ ਕਿ ਉਹ ਇੱਕ ਸਿੰਗਲ, ਵੱਡਾ ਸਿਸਟਮ ਬਣਾਉਣਗੇ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਤੱਤ ਹੋਣਗੇ, ਗਲਤੀ ਦੀ ਸੰਭਾਵਨਾ ਓਨੀ ਹੀ ਜ਼ਿਆਦਾ ਹੋਵੇਗੀ ਅਤੇ ਐਂਟਰੌਪੀ ਓਨੀ ਹੀ ਜ਼ਿਆਦਾ ਹੋਵੇਗੀ।

ਸਾਡੇ ਮਾਮਲੇ ਵਿੱਚ, ਉੱਚ ਲੇਟੈਂਸੀ Kubernetes, KIAM, AWS Java SDK, ਜਾਂ ਸਾਡੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ ਬੱਗਾਂ ਜਾਂ ਮਾੜੇ ਫੈਸਲਿਆਂ ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਸੀ। ਇਹ ਦੋ ਸੁਤੰਤਰ ਡਿਫਾਲਟ ਸੈਟਿੰਗਾਂ ਦਾ ਨਤੀਜਾ ਸੀ: ਇੱਕ KIAM ਵਿੱਚ ਅਤੇ ਇੱਕ AWS Java SDK ਵਿੱਚ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਸਮਝ ਆਉਂਦੀਆਂ ਹਨ: AWS Java SDK ਵਿੱਚ ਸਰਗਰਮ ਸਰਟੀਫਿਕੇਟ ਨਵੀਨੀਕਰਨ ਨੀਤੀ ਅਤੇ KAIM ਵਿੱਚ ਛੋਟਾ ਸਰਟੀਫਿਕੇਟ ਮਿਆਦ ਪੁੱਗਣ ਦਾ ਸਮਾਂ। ਪਰ ਜਦੋਂ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨਤੀਜੇ ਅਣਪਛਾਤੇ ਬਣ ਜਾਂਦੇ ਹਨ। ਦੋ ਸੁਤੰਤਰ ਅਤੇ ਤਰਕਪੂਰਨ ਹੱਲ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਇਕੱਠੇ ਕੀਤੇ ਜਾਣ 'ਤੇ ਕੋਈ ਅਰਥ ਹੋਵੇ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਤੁਸੀਂ AWS IAM ਨੂੰ Kubernetes ਨਾਲ ਜੋੜਨ ਲਈ KIAM ਉਪਯੋਗਤਾ ਦੇ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਹੋਰ ਜਾਣ ਸਕਦੇ ਹੋ ਇਸ ਲੇਖ ਇਸਦੇ ਸਿਰਜਣਹਾਰਾਂ ਤੋਂ।

ਅਤੇ ਸਾਡੇ ਬਲੌਗ ਵਿੱਚ, ਤੁਸੀਂ ਇਹ ਵੀ ਪੜ੍ਹ ਸਕਦੇ ਹੋ:

• «3 ਕੁਬਰਨੇਟਸ ਪ੍ਰੋਡਕਸ਼ਨ ਅਸਫਲਤਾ ਕਹਾਣੀਆਂ: ਐਂਟੀ-ਐਫਿਨਿਟੀ, ਗ੍ਰੇਸਫੁੱਲ ਸ਼ਟਡਾਊਨ, ਅਤੇ ਵੈੱਬਹੁੱਕ";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਪੌਡ ਦੀਆਂ ਤਰਜੀਹਾਂ ਨੇ ਗ੍ਰਾਫਾਨਾ ਲੈਬਜ਼ ਵਿੱਚ ਡਾਊਨਟਾਈਮ ਕਿਵੇਂ ਕੀਤਾ";
• «ਕੁਬਰਨੇਟਸ [ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ] ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ 6 ਮਨੋਰੰਜਕ ਸਿਸਟਮ ਬੱਗ";
• «ਸਾਡੇ SRE ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਤੋਂ 6 ਵਿਹਾਰਕ ਕਹਾਣੀਆਂ".

ਸਰੋਤ: www.habr.com