Kubernetes ਅਤੇ OpenVPN ਸਾਈਡਕਾਰ ਵਿੱਚਕਾਰ DNS ਨੂੰ ਕਿਵੇਂ ਵੰਡੀਏ

ਸਾਈਡਕਾਰ ਪੋਡ ਨੂੰ ਦੋ ਨਾਮ-ਸੰਸਾਰ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਲੂਪਬੈਕ ਰਿਜ਼ੋਲਵਰ ਕਲਸਟਰ ਅਤੇ ਟਨਲ ਵੱਲ ਮੋੜੋ, ਅਤੇ ਸੰਪਾਦਿਤ resolv.conf 'ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਬੰਦ ਕਰੋ।

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

ਤੁਹਾਡੀ ਕੀਤੀ ਤਬਦੀਲੀ ਹਰ ਵਾਰ ਕਿਉਂ ਗਾਇਬ ਹੁੰਦੀ ਹੈ

ਫਾਈਲ kubelet ਦੀ ਹੈ, ਤੁਹਾਡੀ ਨਹੀਂ। dnsPolicy: ClusterFirst ਅਧੀਨ kubelet ਇਸਨੂੰ ਕਲਸਟਰ DNS ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਲਈ ਬਣਾਉੰਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਹਰ ਵਾਰ ਮੁੜ ਬਣਾਉੰਦਾ ਹੈ। kubectl exec ਰਾਹੀਂ ਤੁਸੀਂ ਜੋ ਬਦਲਦੇ ਹੋ ਉਹ ਕੰਟੇਨਰ ਦੀ ਲਿਖਣਯੋਗ ਪਰਤ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਮੁੜ ਚਾਲੂ ਕਰਨਾ, ਬਾਹਰ ਕੱਢਨਾ ਜਾਂ ਰੋਲਆਉਟ ਉਸਨੂੰ ਸੁੱਟ ਦਿੰਦੇ ਹਨ। ਪੋਡ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਅਜੇ ਵੀ ਉਹੀ ਨੀਤੀ ਰੱਖਦੀ ਹੈ, ਇਸ ਲਈ ਉਹੀ ਫਾਈਲ ਵਾਪਸ ਆਉੰਦੀ ਹੈ।

dnsPolicy: None ਸੈਟ ਕਰਨ ਨਾਲ ਮੁੜ-ਨਿਰਮਾਣ ਰੁੱਕਦਾ ਹੈ ਅਤੇ ਕਲਸਟਰ ਹੱਲ ਵੀ ਹੱਟ ਜਾੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਕੰਟਰੋਲ ਵਾਲੀ ਫਾਈਲ ਮਿਲਦੀ ਹੈ ਅਤੇ ਲੋੜੀੰਦੇ ਨਾਮ ਗੁਆਚ ਜਾੰਦੇ ਹਨ। ਇਹ ਤਬਾਦਲਾ ਹੀ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ: resolv.conf ਨੂੰ ਜ਼ੋਨ ਦੀ ਧਾਰਣਾ ਨਹੀਂ, ਸਿਰਫ਼ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਣ ਵਾਲੇ ਸਰਵਰ, ਇਸ ਲਈ ਇਹ cluster.local ਨੂੰ ਇੱਕ ਪਤੇ 'ਤੇ ਅਤੇ ਨਿੱਜੀ ਜ਼ੋਨ ਨੂੰ ਦੂਜੇ ਪਤੇ 'ਤੇ ਨਹੀਂ ਭੇਜ ਸਕਦਾ।

ਪੋਡ ਵਿੱਚ ਇੱਕ ਰਿਜ਼ੋਲਵਰ ਚਲਾਓ, ਲੂਪਬੈਕ 'ਤੇ

ਪੋਡ ਨੂੰ ਲੂਪਬੈਕ ਦੇ ਇੱਕ ਨੇਮਸਰਵਰ ਵੱਲ ਮੋੜੋ, ਫਿਰ ਪੋਡ ਦੀ ਨੈਟਵਰਕ ਨਾਮ-ਥਾਂ ਸਾੰਝੀ ਕਰਨ ਵਾਲੇ CoreDNS ਕੰਟੇਨਰ ਨੂੰ ਪੋਰਟ 53 'ਤੇ ਜਵਾਬ ਦੇਣ ਦਿਓ। ਨੀਤੀ None 'ਤੇ ਸੈਟ ਕਰੋ, ਪੋਡ ਨੂੰ ਉਹ ਇੱਕ ਪਤਾ ਦਿਓ, ਅਤੇ VPN ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੋਲ DNS ਕੰਟੇਨਰ ਜੋੜੋ:

spec:
  dnsPolicy: None
  dnsConfig:
    nameservers:
      - 127.0.0.1
    options:
      - name: ndots
        value: "5"
  containers:
    - name: dns
      image: coredns/coredns
      args: ["-conf", "/etc/coredns/Corefile"]
      volumeMounts:
        - {name: corefile, mountPath: /etc/coredns, readOnly: true}
    - name: vpn
      image: your-openvpn-client-image
    - name: app
      image: your-app-image
  volumes:
    - name: corefile
      configMap:
        name: split-dns-corefile

ਤਿੰਨੇਂ ਕੰਟੇਨਰ ਇੱਕ ਨੈਟਵਰਕ ਨਾਮ-ਥਾਂ ਸਾੰਝੀ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਕੰਟੇਨਰ ਤੋਂ 127.0.0.1:53 ਸੇਵਾ ਤੋਂ ਬਿਨਾਂ, port-forward ਤੋਂ ਬਿਨਾਂ ਅਤੇ ਕਲਸਟਰ ਨੈਟਵਰਕ ਰਾਹੀਂ ਘੂੰਮੇ ਬਿਨਾਂ CoreDNS ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ConfigMap ਤੋਂ Corefile ਮਾਊਂਟ ਕਰਨਾ ਇਸਨੂੰ ਉੱਥੇ ਸੰਪਾਦਿਤ ਹੋਣ ਵਾਲੀ ਫਾਈਲ ਦੀ ਥਾਂ ਸੰਸਕਰਣਬੱਧ ਇਨਪੁੱਟ ਰੱਖਦਾ ਹੈ। ਤਿਆਰ ਹੋਇਆ resolv.conf ਫਿਰ ਇੱਕ ਨੇਮਸਰਵਰ ਅਤੇ ਹੋਰ ਕੁੱਝ ਨਹੀਂ ਰੱਖਦਾ, ਇਹ ਅਜੇਹੀ ਹਾਲਤ ਹੈ ਜਿਸ ਬਾਰੇ ਤਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਦੋ ਵਿਵਰਣ ਡੰਗਦੇ ਹਨ। ਸਰਕਾਰੀ ਇਮੇਜ ਪੋਰਟ 53 ਨੂੰ root ਵਜੋਂ ਬੰਨਦੀ ਹੈ, ਅਤੇ ਕੁੱਝ ਕਲਸਟਰ ਨੀਤੀਆਂ ਇਸਨੂੰ ਸੱਪਸਟ ਲਿਖਣ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ। ਪੋਡ ਦਾ ਹਰ ਕੰਟੇਨਰ ਹੁਣ ਉਸ ਇੱਕ ਕੰਟੇਨਰ ਦੇ ਚਲਣ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਇਸ ਲਈ ਨੁੱਕਸਾਨ-ਰਹਿਤ ਨਾਮ 'ਤੇ readiness ਪ੍ਰੋਬ ਜੋੜੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਅਸਫਲਤਾ ਸਹਣ ਦਿਓ।

ਹਰ ਨਿੱਜੀ ਜ਼ੋਨ ਨੂੰ ਆਪਣਾ upstream ਦਿਓ

Corefile ਜ਼ੋਨਾਂ ਦੀ ਸੂਚੀ ਹੈ, ਹਰ ਇੱਕ ਉਸ ਸਰਵਰ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਬਲਾਕ ਟਨਲ ਜ਼ੋਨ ਨੂੰ ਢੰਕਦਾ ਹੈ, ਅਤੇ ਸਭ ਫੜਨ ਵਾਲਾ ਬਲਾਕ ਸਭ ਤੋਂ ਬਾਦ ਆਉੰਦਾ ਹੈ ਅਤੇ ਜੋ ਕਿਸੇ ਸੱਪਸਟ ਬਲਾਕ ਨੇ ਦਾਵਾ ਨਹੀਂ ਕੀਤਾ ਉਹ ਸਭ ਲੈਂਦਾ ਹੈ। ਸਭ ਫੜਨ ਵਾਲੇ ਬਲਾਕ ਨੂੰ ਅਸਲੀ upstream ਵੱਲ ਨਿਸ਼ਾਨਾ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਦੇ ਵੀ ਪੋਡ ਵੱਲ ਵਾਪਸ ਨਹੀਂ: .:53 { forward . 10.100.0.10 } ਕਲਸਟਰ ਰਿਜ਼ੋਲਵਰ ਮੁੜ ਵਰਤਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਸਾਰਵਜਨਿਕ ਨਾਮ ਨੋਡ ਦੇ ਆਪਣੇ ਰਿਜ਼ੋਲਵਰਾਂ ਵੱਲ ਭੇਜਦਾ ਹੈ। ਪੋਡ ਵਿੱਚ ਹੋਰ ਕਿਸੇ ਨੂੰ ਵੀ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਨਾਮ ਕਿਹੜੇ ਨੈਟਵਰਕ ਦਾ ਹੈ।

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

svc.acme.internal:53 {
  errors
  cache 30
  forward . 192.168.240.1
}

ਕਲਸਟਰ ਪਤਾ ਲੇਖ ਤੋਂ ਨਕਲ ਕਰਨ ਦੀ ਥਾਂ kube-system ਵਿੱਚ kube-dns ਸੇਵਾ ਤੋਂ ਪੜੋ, ਕਿਉਂਕਿ ਸੇਵਾ CIDR ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਟਨਲ ਪਤਾ OpenVPN ਸਰਵਰ ਭੇਜਦਾ dhcp-option DNS ਮੁੱਲ ਤੋਂ ਜਾਂ ਉਸ ਜ਼ੋਨ ਦੇ ਅਧਿਕਾਰਤ ਸਰਵਰ ਤੋਂ ਆਉੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਕਲਸਟਰ ਰਿਜ਼ੋਲਵਰ ਸਾਰਵਜਨਿਕ ਨਾਮਾਂ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦੇਂਦਾ, ਤਾਂ ਨੋਡ ਦੇ ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ ਸਭ ਫੜਨ ਵਾਲੇ ਬਲਾਕ ਵਿੱਚ ਰੱਖੋ, ਉਹ ਨੋਡ 'ਤੇ ਪੜਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪੋਡ ਵਿੱਚ ਨਹੀਂ।

ਸਭ ਫੜਨ ਵਾਲੇ ਬਲਾਕ ਨੂੰ /etc/resolv.conf ਵੱਲ ਨਾ ਮੋੜੋ, ਉਹ ਲੁਭਾਉਣ ਵਾਲੀ ਇੱਕ ਲਾਈਨ ਅਤੇ ਇਸੇ ਢਾੰਚੇ ਵਿੱਚ ਜਾਲ ਹੈ। dnsPolicy: None ਅਧੀਨ ਪੋਡ ਦੀ ਆਪਣੀ ਫਾਈਲ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਨੇਮਸਰਵਰ 127.0.0.1 ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਨਿਸ਼ਾਨਾ CoreDNS ਆਪ ਹੈ ਅਤੇ ਹਰ ਨਾ-ਮਿਲਦੀ ਕ੍ਵੇਰੀ ਸਮਾਂ ਖਤਮ ਹੋਣ ਤੱਕ ਦੁਹਰਾਈ ਜਾੰਦੀ ਹੈ। svc.acme.internal ਨਾਮ ਦਾ ਬਲਾਕ ਉਸ ਨਾਮ ਅਤੇ ਉਸ ਹੇਠਲੇ ਹਰ ਨਾਮ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਜੋ db.svc.acme.internal ਨੂੰ ਢੰਕਦਾ ਅਤੇ svc.acme.internal.example.net ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਅੰਤਲਾ ਬਿੰਦੂ ਦਿੱਖ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਕਿਉਂਕਿ ਜ਼ੋਨ ਨਾਮ ਪੂਰੀ ਤਰਾਂ ਯੋਗਤਾ ਵਾਲੇ ਰੂਪ ਵਿੱਚ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ; ਪਿੰਛੇਤਰ ਦੀ ਹੱਦ ਤਯ ਕਰਦੀ ਹੈ ਕ੍ਵੇਰੀ ਕਿੱਥੇ ਉਤਰਦੀ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਕਲਸਟਰ ਰਿਜ਼ੋਲਵਰ ਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਤਯ ਕਰੋ

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

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

ਉਹ ਨਾਮ ਜੋ ਕਨੈਕਸ਼ਨ ਅਜੇ ਅਸਫਲ ਹੁੰਦਿਆਂ ਵੀ ਹੱਲ ਹੁੰਦੇ ਹਨ

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

ਸਰਵਰ ਨੂੰ hostNetwork: true ਨਾਲ ਚਲਾਉਣ ਨਾਲ ਉਹ ਨੋਡ ਦੀ ਨਾਮ-ਥਾਂ ਵਿੱਚ ਵਾਪਸ ਆਉੰਦਾ ਹੈ, ਜਿੱਥੇ FORWARD ਨਿਯਮ ਅਤੇ ਸਰੋਤ ਅਨੁਵਾਦ ਕੰਮ ਕਰਦੇ ਹਨ। ਬਾਹਰ ਜਾਣ ਸਮੇਂ ਕਲਾਇਰੈੰਟ ਪੂਲ ਦਾ ਅਨੁਵਾਦ ਕਰੋ, ਨਹੀਂ ਤਾਂ 10.8.0.6 ਵਰਗੇ ਟਨਲ ਪਤੇ ਵਾਪਸੀ ਰਾਹ ਕਿਸੇ ਵੀ ਦੂਰ ਦੇ ਨੋਡ ਕੋਲ ਨਹੀਂ ਹੋਵੇਗੀ। Corefile ਨੂੰ ਮੁੜ ਛੁੱਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਜਾੰਚੋ। ਕ੍ਵੇਰੀ ਲੈ ਜਾਣ ਵਾਲਾ ਪਰ ਜਵਾਬ ਨ ਲੈ ਜਾਣ ਵਾਲਾ ਟਨਲ, ਕ੍ਵੇਰੀ ਕਦੇ ਨ ਮਿਲੀ ਰਿਜ਼ੋਲਵਰ ਵਾੰਗੂਂ ਹੀ ਟਾਈਮਆਉਟ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਤੁਹਾਡੇ ਠੀਕ ਕੀਤੇ ਸੈਸ਼ਨ ਤੋਂ ਨਹੀਂ, ਨਵੇ ਪੋਡ ਤੋਂ ਜਾੰਚੋ

ਦੋਵੇਂ ਜ਼ੋਨਾਂ ਨੂੰ ਸੱਪਸਟ ਪੁੱਛੋ, ਫਿਰ ਪੋਡ ਬਦਲਣ ਤੋਂ ਬਾਦ ਕ੍ਵੇਰੀ ਦੁਹਰਾਓ। ਸਿਰਫ਼ ਚਲਦੇ ਕੰਟੇਨਰ ਵਿੱਚ ਹੀ ਮੌਜੂਦ ਸੰਰਚਨਾ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ:

kubectl exec -it deploy/app -- dig @127.0.0.1 kubernetes.default.svc.cluster.local +short
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short
kubectl delete pod -l app=your-app
kubectl wait --for=condition=Ready pod -l app=your-app --timeout=90s
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short

ਜੇ ਪਹਿਲੀ ਜੋੜੀ ਜਵਾਬ ਦੇਂਦੀ ਹੈ ਅਤੇ ਬਦਲਣ ਤੋਂ ਬਾਦ ਵਾਲੀ ਜੋੜੀ ਨਹੀਂ, ਤਾਂ Corefile ਠੀਕ ਹੈ ਅਤੇ ਪੋਡ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨਹੀਂ। ਜੇ ਦੋਵੇਂ ਜਵਾਬ ਦੇਂਦੀਆਂ ਹਨ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਅਜੇ ਵੀ ਜੁੜ ਨਹੀਂ ਸਕਦੀ, ਤਾਂ DNS ਡੀਬੱਗ ਕਰਨਾ ਬੰਦ ਕਰੋ ਅਤੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰੋਂ nc -vz db.svc.acme.internal 5432 ਨਾਲ TCP ਰਾਹ ਜਾੰਚੋ। dig ਦਾ ਆਉਟਪੁੱਟ ਟਿਕਟ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹੀ ਨਾਮ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਰਾਊਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨ ਵਾਲੀ ਕਲਾਕ੃ਤੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ