ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਕੁਬਰਨੇਟਸ ਵਿੱਚ DNS ਸਮੱਸਿਆ, ਜਾਂ ਹੋਰ ਸਹੀ ਰੂਪ ਵਿੱਚ, ਪੈਰਾਮੀਟਰ ਸੈਟਿੰਗਾਂ ndots
, ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਪ੍ਰਸਿੱਧ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ
ਕੁਬਰਨੇਟਸ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਮੁੱਖ ਲਾਭਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਸਹਿਜ ਐਪਲੀਕੇਸ਼ਨ ਖੋਜ। ਸੇਵਾ ਸੰਕਲਪ (vanilla
ਸੇਵਾ ਨਾਲ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ chocolate
, ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵਰਚੁਅਲ IP ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ chocolate
. ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੌਣ DNS ਬੇਨਤੀ ਨੂੰ ਹੱਲ ਕਰੇਗਾ chocolate
ਅਤੇ ਕਿਵੇਂ?
DNS ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ /etc/resolv.conf
ਸਾਰੀਆਂ ਫਲੀਆਂ ਜੇ ਤੁਸੀਂ ਸਮੱਗਰੀ ਨੂੰ ਦੇਖਦੇ ਹੋ /etc/resolv.conf
ਕੋਈ ਵੀ ਪੋਡ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
ਇਸ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ DNS ਕਲਾਇੰਟਸ ਦੁਆਰਾ ਬੇਨਤੀਆਂ ਨੂੰ DNS ਸਰਵਰ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਫਾਈਲ ਵਿੱਚ resolv.conf
ਹੇਠ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਿਲ ਹੈ:
- ਨੇਮਸਰਵਰ: ਸਰਵਰ ਜਿਸ ਨੂੰ DNS ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਜਾਣਗੀਆਂ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ CoreDNS ਸੇਵਾ ਦਾ ਪਤਾ ਹੈ;
- ਖੋਜ: ਕਿਸੇ ਖਾਸ ਡੋਮੇਨ ਲਈ ਖੋਜ ਮਾਰਗ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਦਿਲਚਸਪ ਹੈ ਕਿ
google.com
ਜmrkaran.dev
FQDN ਨਹੀਂ ਹਨ (ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਡੋਮੇਨ ਨਾਮ ). ਸਟੈਂਡਰਡ ਕਨਵੈਨਸ਼ਨ ਦੇ ਅਨੁਸਾਰ ਜਿਸਦਾ ਪਾਲਣ ਜ਼ਿਆਦਾਤਰ DNS ਰੈਜ਼ੋਲਵਰ ਕਰਦੇ ਹਨ, ਸਿਰਫ ਉਹੀ ਜੋ ਇੱਕ ਬਿੰਦੂ "." ਨਾਲ ਖਤਮ ਹੁੰਦੇ ਹਨ, ਰੂਟ ਜ਼ੋਨ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ (FDQN) ਡੋਮੇਨ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਹੱਲ ਕਰਨ ਵਾਲੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਬਿੰਦੂ ਜੋੜ ਸਕਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ,mrkaran.dev.
ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਡੋਮੇਨ ਨਾਮ (FQDN), ਅਤੇmrkaran.dev
- ਨਹੀਂ; - ndots: ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਪੈਰਾਮੀਟਰ (ਇਹ ਲੇਖ ਇਸ ਬਾਰੇ ਹੈ).
ndots
ਬੇਨਤੀ ਨਾਮ ਵਿੱਚ ਬਿੰਦੀਆਂ ਦੀ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੰਖਿਆ ਨੂੰ "ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ" ਡੋਮੇਨ ਨਾਮ ਮੰਨੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗੇ ਜਦੋਂ ਅਸੀਂ DNS ਲੁੱਕਅਪ ਕ੍ਰਮ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ।
ਆਓ ਦੇਖੀਏ ਕਿ ਜਦੋਂ ਅਸੀਂ ਪੁੱਛਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ mrkaran.dev
ਪੌਡ ਵਿੱਚ:
$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
ਇਸ ਪ੍ਰਯੋਗ ਲਈ, ਮੈਂ CoreDNS ਲੌਗਿੰਗ ਪੱਧਰ ਨੂੰ ਸੈੱਟ ਕੀਤਾ ਹੈ all
(ਜੋ ਇਸਨੂੰ ਕਾਫ਼ੀ ਸ਼ਬਦਾਵਲੀ ਬਣਾਉਂਦਾ ਹੈ)। ਆਉ ਪੌਡ ਦੇ ਲੌਗਸ ਨੂੰ ਵੇਖੀਏ coredns
:
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s
ਫੂ. ਇੱਥੇ ਦੋ ਗੱਲਾਂ ਤੁਹਾਡਾ ਧਿਆਨ ਖਿੱਚਦੀਆਂ ਹਨ:
- ਬੇਨਤੀ ਖੋਜ ਦੇ ਸਾਰੇ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਜਵਾਬ ਵਿੱਚ ਕੋਡ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ
NOERROR
(DNS ਕਲਾਇੰਟ ਇਸ ਨੂੰ ਸਮਝਦੇ ਹਨ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਇਸਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ).NXDOMAIN
ਮਤਲਬ ਕਿ ਦਿੱਤੇ ਗਏ ਡੋਮੇਨ ਨਾਮ ਲਈ ਕੋਈ ਰਿਕਾਰਡ ਨਹੀਂ ਮਿਲਿਆ। ਕਿਉਂਕਿ ਦmrkaran.dev
ਇੱਕ FQDN ਨਾਮ ਨਹੀਂ ਹੈ (ਦੇ ਅਨੁਸਾਰndots=5
), ਰੈਜ਼ੋਲਵਰ ਖੋਜ ਮਾਰਗ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀਆਂ ਦਾ ਕ੍ਰਮ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ; - ਰਿਕਾਰਡ
А
иАААА
ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਪਹੁੰਚੋ. ਤੱਥ ਇਹ ਹੈ ਕਿ ਵਿੱਚ ਇੱਕ ਵਾਰ ਦੀ ਬੇਨਤੀ/etc/resolv.conf
ਮੂਲ ਰੂਪ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ IPv4 ਅਤੇ IPv6 ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਮਾਨਾਂਤਰ ਖੋਜਾਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਵਿਕਲਪ ਨੂੰ ਜੋੜ ਕੇ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋsingle-request
вresolv.conf
.
ਨੋਟ: glibc
ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਭੇਜਣ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ musl
- ਨਹੀਂ, ਇਸ ਲਈ ਐਲਪਾਈਨ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ndots ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ
ਦੇ ਨਾਲ ਥੋੜਾ ਹੋਰ ਪ੍ਰਯੋਗ ਕਰੀਏ ndots
ਅਤੇ ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਪੈਰਾਮੀਟਰ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ndots
ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ DNS ਕਲਾਇੰਟ ਡੋਮੇਨ ਨੂੰ ਸੰਪੂਰਨ ਜਾਂ ਰਿਸ਼ਤੇਦਾਰ ਸਮਝੇਗਾ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਧਾਰਨ google DNS ਕਲਾਇੰਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਕਿਵੇਂ ਜਾਣਦਾ ਹੈ ਕਿ ਇਹ ਡੋਮੇਨ ਸੰਪੂਰਨ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ ਸੈਟ ਕਰਦੇ ਹੋ ndots
1 ਦੇ ਬਰਾਬਰ, ਗਾਹਕ ਕਹੇਗਾ: "ਓਹ, ਵਿੱਚ google
ਇੱਥੇ ਇੱਕ ਵੀ ਬਿੰਦੂ ਨਹੀਂ ਹੈ; ਮੇਰਾ ਅੰਦਾਜ਼ਾ ਹੈ ਕਿ ਮੈਂ ਪੂਰੀ ਖੋਜ ਸੂਚੀ ਵਿੱਚੋਂ ਲੰਘਾਂਗਾ।" ਹਾਲਾਂਕਿ, ਜੇ ਤੁਸੀਂ ਪੁੱਛੋ google.com
, ਪਿਛੇਤਰਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਡਿੱਠ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਬੇਨਤੀ ਕੀਤਾ ਨਾਮ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ndots
(ਘੱਟੋ ਘੱਟ ਇੱਕ ਬਿੰਦੂ ਹੈ)।
ਆਓ ਇਹ ਯਕੀਨੀ ਕਰੀਏ:
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAIN
CoreDNS ਲੌਗਸ:
[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
ਜਦੋਂ ਤੋਂ mrkaran
ਇੱਥੇ ਇੱਕ ਵੀ ਬਿੰਦੂ ਨਹੀਂ ਹੈ, ਖੋਜ ਪਿਛੇਤਰਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਵਿੱਚ ਕੀਤੀ ਗਈ ਸੀ।
ਨੋਟ: ਅਭਿਆਸ ਵਿੱਚ ਅਧਿਕਤਮ ਮੁੱਲ ndots
15 ਤੱਕ ਸੀਮਿਤ; ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ 5 ਹੈ।
ਉਤਪਾਦਨ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ
ਜੇਕਰ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਸਾਰੀਆਂ ਬਾਹਰੀ ਨੈਟਵਰਕ ਕਾਲਾਂ ਕਰਦੀ ਹੈ, ਤਾਂ DNS ਸਰਗਰਮ ਟ੍ਰੈਫਿਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਲੋੜੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਕਰਦਾ ਹੈ (ਸਿਸਟਮ ਦੇ ਸਹੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ)। ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡੋਮੇਨ ਨਾਮਾਂ ਵਿੱਚ ਰੂਟ ਜ਼ੋਨ ਨਹੀਂ ਜੋੜਦੀਆਂ, ਪਰ ਇਹ ਇੱਕ ਹੈਕ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਭਾਵ, ਪੁੱਛਣ ਦੀ ਬਜਾਏ api.twitter.com
, ਤੁਸੀਂ ਹਾਰਡਕੋਡ ਕਰ ਸਕਦੇ ਹੋ api.twitter.com.
ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ (ਇੱਕ ਬਿੰਦੀ ਦੇ ਨਾਲ), ਜੋ ਕਿ DNS ਕਲਾਇੰਟਸ ਨੂੰ ਸਿੱਧੇ ਪੂਰਨ ਡੋਮੇਨ 'ਤੇ ਅਧਿਕਾਰਤ ਖੋਜ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰੇਗਾ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬਰਨੇਟਸ ਸੰਸਕਰਣ 1.14, ਐਕਸਟੈਂਸ਼ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ dnsConfig
и dnsPolicy
ਸਥਿਰ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕੀਤੀ. ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਇੱਕ ਪੌਡ ਤਾਇਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੁੱਲ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ ndots
, ਕਹੋ, 3 ਤੱਕ (ਅਤੇ 1 ਤੱਕ ਵੀ!) ਇਸਦੇ ਕਾਰਨ, ਇੱਕ ਨੋਡ ਦੇ ਅੰਦਰ ਹਰੇਕ ਸੰਦੇਸ਼ ਵਿੱਚ ਪੂਰਾ ਡੋਮੇਨ ਸ਼ਾਮਲ ਕਰਨਾ ਹੋਵੇਗਾ। ਇਹ ਕਲਾਸਿਕ ਟ੍ਰੇਡ-ਆਫਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੋਰਟੇਬਿਲਟੀ ਵਿਚਕਾਰ ਚੋਣ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਿਰਫ ਇਸ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਅਤਿ-ਘੱਟ ਲੇਟੈਂਸੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ DNS ਨਤੀਜੇ ਵੀ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਹਵਾਲੇ
ਮੈਨੂੰ ਪਹਿਲੀ ਵਾਰ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਰੇ ਪਤਾ ਲੱਗਾ
ਹੋਰ ਖੋਜ ਲਈ ਇੱਥੇ ਕੁਝ ਲਿੰਕ ਹਨ:
-
ਵਿਆਖਿਆ , ਕੁਬਰਨੇਟਸ ਵਿੱਚ ndots=5 ਕਿਉਂ; -
ਮਹਾਨ ਸਮੱਗਰੀ ndots ਬਦਲਣ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ; -
ਮਤਭੇਦ musl ਅਤੇ glibc ਰੈਜ਼ੋਲਵਰ ਵਿਚਕਾਰ.
ਨੋਟ: ਮੈਂ ਨਾ ਵਰਤਣਾ ਚੁਣਿਆ dig
ਇਸ ਲੇਖ ਵਿਚ dig
ਡੋਮੇਨ ਨੂੰ "ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ" (FQDN) ਬਣਾਉਂਦੇ ਹੋਏ, ਆਪਣੇ ਆਪ ਇੱਕ ਬਿੰਦੀ (ਰੂਟ ਜ਼ੋਨ ਪਛਾਣਕਰਤਾ) ਜੋੜਦਾ ਹੈ, ਨਾ ਪਹਿਲਾਂ ਇਸਨੂੰ ਖੋਜ ਸੂਚੀ ਦੁਆਰਾ ਚਲਾ ਕੇ। ਵਿਚ ਇਸ ਬਾਰੇ ਲਿਖਿਆ
DNSing ਮੁਬਾਰਕ! ਫਿਰ ਮਿਲਦੇ ਹਾਂ!
ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ
ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:
- «
ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਕੈਲੀਕੋ: ਜਾਣ-ਪਛਾਣ ਅਤੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਅਨੁਭਵ "; - «
CoreDNS - ਕਲਾਉਡ ਨੇਟਿਵ ਵਰਲਡ ਲਈ DNS ਸਰਵਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਲਈ ਸਰਵਿਸ ਡਿਸਕਵਰੀ "; - "ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਇੱਕ ਇਲਸਟ੍ਰੇਟਿਡ ਗਾਈਡ":
ਭਾਗ 1 ਅਤੇ 2 (ਨੈੱਟਵਰਕ ਮਾਡਲ, ਓਵਰਲੇ ਨੈੱਟਵਰਕ) ,ਭਾਗ 3 (ਸੇਵਾਵਾਂ ਅਤੇ ਟ੍ਰੈਫਿਕ ਪ੍ਰੋਸੈਸਿੰਗ) .
ਸਰੋਤ: www.habr.com