ನಾವು ಇತ್ತೀಚೆಗೆ Kops ಅನ್ನು ಬಳಸಿಕೊಂಡು AWS ನಲ್ಲಿ Kubernetes 1.9 ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಿನ್ನೆ, ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ದೊಡ್ಡದಕ್ಕೆ ಹೊಸ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸರಾಗವಾಗಿ ಹೊರತರುತ್ತಿರುವಾಗ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಲಾಗ್ ಮಾಡಲಾದ ಅಸಾಮಾನ್ಯ DNS ಹೆಸರು ರೆಸಲ್ಯೂಶನ್ ದೋಷಗಳನ್ನು ನಾನು ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ.
GitHub ನಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಇದೆ , ಹಾಗಾಗಿ ನಾನು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ. ಕೊನೆಯಲ್ಲಿ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಹೆಚ್ಚಿದ ಹೊರೆಯಿಂದ ಉಂಟಾಗುತ್ತದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ kube-dns и dnsmasq. ನನಗೆ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಹೊಸ ವಿಷಯವೆಂದರೆ DNS ವಿನಂತಿಯ ದಟ್ಟಣೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ನನ್ನ ಪೋಸ್ಟ್ ಇದರ ಬಗ್ಗೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬೇಕು.
ಕಂಟೇನರ್ ಒಳಗೆ DNS ರೆಸಲ್ಯೂಶನ್ - ಯಾವುದೇ ಲಿನಕ್ಸ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವಂತೆ - ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ /etc/resolv.conf. ಡೀಫಾಲ್ಟ್ ಕುಬರ್ನೆಟ್ಸ್ dnsPolicy ಇದು ClusterFirst, ಅಂದರೆ ಯಾವುದೇ DNS ವಿನಂತಿಯನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ dnsmasq, ಪಾಡ್‌ನಲ್ಲಿ ಓಡುತ್ತಿದೆ kube-dns ಕ್ಲಸ್ಟರ್ ಒಳಗೆ, ಇದು ಅರ್ಜಿಗೆ ವಿನಂತಿಯನ್ನು ರವಾನಿಸುತ್ತದೆ kube-dns, ಹೆಸರು ಕ್ಲಸ್ಟರ್ ಪ್ರತ್ಯಯದೊಂದಿಗೆ ಕೊನೆಗೊಂಡರೆ, ಅಥವಾ, ಇಲ್ಲದಿದ್ದರೆ, ಉನ್ನತ ಮಟ್ಟದ DNS ಸರ್ವರ್‌ಗೆ.
ಕಡತ /etc/resolv.conf ಪ್ರತಿ ಕಂಟೇನರ್ ಒಳಗೆ ಡೀಫಾಲ್ಟ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
eu-west-1.compute.internal
options ndots:5ನೀವು ನೋಡುವಂತೆ, ಮೂರು ನಿರ್ದೇಶನಗಳಿವೆ:
- ಹೆಸರು ಸರ್ವರ್ ಸೇವೆಯ IP ಆಗಿದೆ
kube-dns - 4 ಸ್ಥಳೀಯ ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ
search - ಒಂದು ಆಯ್ಕೆ ಇದೆ
ndots:5
ಸ್ಥಳೀಯ ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಹೇಗೆ ಎಂಬುದು ಈ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಆಸಕ್ತಿದಾಯಕ ಭಾಗವಾಗಿದೆ ndots:5 ಒಟ್ಟಿಗೆ ಬೆರೆಯಿರಿ. ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಅನರ್ಹ ಹೆಸರುಗಳಿಗಾಗಿ DNS ರೆಸಲ್ಯೂಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಪೂರ್ಣ ಹೆಸರೇನು?
ಸಂಪೂರ್ಣ ಅರ್ಹವಾದ ಹೆಸರು ಯಾವುದೇ ಸ್ಥಳೀಯ ಲುಕಪ್ ಅನ್ನು ನಿರ್ವಹಿಸದ ಹೆಸರಾಗಿದೆ ಮತ್ತು ಹೆಸರು ರೆಸಲ್ಯೂಶನ್ ಸಮಯದಲ್ಲಿ ಹೆಸರನ್ನು ಸಂಪೂರ್ಣವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಸಂಪ್ರದಾಯದ ಪ್ರಕಾರ, DNS ಸಾಫ್ಟ್‌ವೇರ್ ಹೆಸರನ್ನು ಡಾಟ್ (.) ನೊಂದಿಗೆ ಕೊನೆಗೊಳಿಸಿದರೆ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಹತೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಹತೆ ಹೊಂದಿಲ್ಲ. ಅದು google.com. ಸಂಪೂರ್ಣವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಮತ್ತು google.com - ಇಲ್ಲ.
ಅರ್ಹವಲ್ಲದ ಹೆಸರನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ?
ಹೆಸರಿನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ರಿಮೋಟ್ ಹೋಸ್ಟ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದಾಗ, DNS ಹೆಸರಿನ ರೆಸಲ್ಯೂಶನ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ, ಉದಾ. getaddrinfo(). ಆದರೆ ಹೆಸರು ಅನರ್ಹವಾಗಿದ್ದರೆ (ಎಂದು ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ.), ಸಿಸ್ಟಮ್ ಕರೆ ಮೊದಲು ಹೆಸರನ್ನು ಸಂಪೂರ್ಣ ಹೆಸರಾಗಿ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಅಥವಾ ಮೊದಲು ಸ್ಥಳೀಯ ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳ ಮೂಲಕ ಹೋಗಬಹುದೇ ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ? ಇದು ಆಯ್ಕೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ndots.
ಕೈಪಿಡಿಯಿಂದ resolv.conf:
ndots:n
устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.ಇದರರ್ಥ ಒಂದು ವೇಳೆ ndots 5 ರ ಮೌಲ್ಯವನ್ನು ನೀಡಿದರೆ ಮತ್ತು ಹೆಸರು 5 ಕ್ಕಿಂತ ಕಡಿಮೆ ಚುಕ್ಕೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಸಿಸ್ಟಮ್ ಕರೆ ಅದನ್ನು ಅನುಕ್ರಮವಾಗಿ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮೊದಲು ಎಲ್ಲಾ ಸ್ಥಳೀಯ ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳನ್ನು ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ವಿಫಲವಾದರೆ, ಅಂತಿಮವಾಗಿ ಅದನ್ನು ಸಂಪೂರ್ಣ ಹೆಸರಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ.
ಏಕೆ ndots:5 ಇದು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಹುದೇ?
ನೀವು ಊಹಿಸುವಂತೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಹಳಷ್ಟು ಬಾಹ್ಯ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬಳಸಿದರೆ, ಸ್ಥಾಪಿಸಲಾದ ಪ್ರತಿಯೊಂದು TCP ಸಂಪರ್ಕಕ್ಕಾಗಿ (ಅಥವಾ ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಪ್ರತಿ ಹೆಸರಿಗೆ ಪರಿಹರಿಸಲಾಗಿದೆ), ಹೆಸರನ್ನು ಸರಿಯಾಗಿ ಪರಿಹರಿಸುವ ಮೊದಲು ಅದು 5 DNS ಪ್ರಶ್ನೆಗಳನ್ನು ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಮೊದಲು ಹಾದುಹೋಗುತ್ತದೆ 4 ಸ್ಥಳೀಯ ಹುಡುಕಾಟ ಡೊಮೇನ್, ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಸಂಪೂರ್ಣ ಹೆಸರು ರೆಸಲ್ಯೂಶನ್ ವಿನಂತಿಯನ್ನು ನೀಡುತ್ತದೆ.
ಕೆಳಗಿನ ಚಾರ್ಟ್ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಕೆಲವು ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಹವಾದವುಗಳಿಗೆ ಬದಲಾಯಿಸುವ ಮೊದಲು ಮತ್ತು ನಂತರ ನಮ್ಮ 3 kube-dns ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿನ ಒಟ್ಟು ಟ್ರಾಫಿಕ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ.
ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಹಲವಾರು ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಪೂರ್ಣ ಹೆಸರುಗಳಿಗೆ ಬದಲಾಯಿಸುವ ಮೊದಲು ಮತ್ತು ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಸುಪ್ತತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ (ಲಂಬ ನೀಲಿ ರೇಖೆಯು ನಿಯೋಜನೆಯಾಗಿದೆ):
ಪರಿಹಾರ #1 - ಸಂಪೂರ್ಣ ಅರ್ಹವಾದ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ
ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ರಚಿಸುವ ಕೆಲವು ಸ್ಥಿರ ಬಾಹ್ಯ ಹೆಸರುಗಳನ್ನು (ಅಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ) ಹೊಂದಿದ್ದರೆ, ಬಹುಶಃ ಸರಳವಾದ ಪರಿಹಾರವೆಂದರೆ ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಸೇರಿಸುವ ಮೂಲಕ ಸಂಪೂರ್ಣ ಅರ್ಹವಾದವುಗಳಿಗೆ ಬದಲಾಯಿಸುವುದು. ಕೊನೆಯಲ್ಲಿ.
ಇದು ಅಂತಿಮ ಪರಿಹಾರವಲ್ಲ, ಆದರೆ ಇದು ತ್ವರಿತವಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಸ್ವಚ್ಛವಾಗಿಲ್ಲದಿದ್ದರೂ, ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ನಮ್ಮ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಈ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸಿದ್ದೇವೆ, ಅದರ ಫಲಿತಾಂಶಗಳನ್ನು ಮೇಲಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ.
ಪರಿಹಾರ #2 - ಗ್ರಾಹಕೀಕರಣ ndots в dnsConfig
ಕುಬರ್ನೆಟ್ಸ್ 1.9 ರಲ್ಲಿ, ಕಾರ್ಯವು ಆಲ್ಫಾ ಮೋಡ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು (ಬೀಟಾ ಆವೃತ್ತಿ v1.10), ಇದು ಪಾಡ್ ಆಸ್ತಿಯ ಮೂಲಕ DNS ನಿಯತಾಂಕಗಳನ್ನು ಉತ್ತಮವಾಗಿ ನಿಯಂತ್ರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ dnsConfig. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಮೌಲ್ಯವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ ndots ನಿರ್ದಿಷ್ಟ ಪಾಡ್‌ಗಾಗಿ, ಅಂದರೆ.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsConfig:
options:
- name: ndots
value: "1"ಮೂಲಗಳು
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:
ಮೂಲ: www.habr.com