etcd Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਡੇਟਾ ਦੇ ਨਾਲ ਸਾਡਾ ਅਨੁਭਵ ਸਿੱਧਾ (K8s API ਤੋਂ ਬਿਨਾਂ)

ਵੱਧਦੇ ਹੋਏ, ਕਲਾਇੰਟ ਸਾਨੂੰ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ Kubernetes ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਕਹਿ ਰਹੇ ਹਨ: ਤਾਂ ਜੋ ਉਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕੁਝ ਡੇਟਾਬੇਸ ਜਾਂ ਸੇਵਾ ਨਾਲ ਜੁੜ ਸਕਣ, ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲ ਇੱਕ ਸਥਾਨਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜੋੜਨ ਲਈ...

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੀ ਸਥਾਨਕ ਮਸ਼ੀਨ ਤੋਂ ਕਿਸੇ ਸੇਵਾ ਨਾਲ ਜੁੜਨ ਦੀ ਲੋੜ ਹੈ memcached.staging.svc.cluster.local. ਅਸੀਂ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਇੱਕ VPN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਪੌਡ, ਸੇਵਾਵਾਂ ਅਤੇ ਪੁਸ਼ ਕਲੱਸਟਰ DNS ਦੇ ਸਬਨੈੱਟ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹਾਂ। ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਇੱਕ ਗਾਹਕ ਸੇਵਾ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ memcached.staging.svc.cluster.local, ਬੇਨਤੀ ਕਲੱਸਟਰ DNS ਨੂੰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਵਿੱਚ ਕਲੱਸਟਰ ਸੇਵਾ ਨੈੱਟਵਰਕ ਜਾਂ ਪੌਡ ਐਡਰੈੱਸ ਤੋਂ ਇਸ ਸੇਵਾ ਦਾ ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ।

ਅਸੀਂ kubeadm ਦੀ ਵਰਤੋਂ ਕਰਕੇ K8s ਕਲੱਸਟਰਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਦੇ ਹਾਂ, ਜਿੱਥੇ ਡਿਫਾਲਟ ਸੇਵਾ ਸਬਨੈੱਟ ਹੈ 192.168.0.0/16, ਅਤੇ ਪੌਡ ਦਾ ਨੈੱਟਵਰਕ ਹੈ 10.244.0.0/16. ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇੱਥੇ ਕੁਝ ਨੁਕਤੇ ਹਨ:

• ਸਬਨੈੱਟ 192.168.*.* ਅਕਸਰ ਕਲਾਇੰਟ ਆਫਿਸ ਨੈਟਵਰਕ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਵੀ ਅਕਸਰ ਡਿਵੈਲਪਰ ਹੋਮ ਨੈਟਵਰਕ ਵਿੱਚ। ਅਤੇ ਫਿਰ ਅਸੀਂ ਵਿਵਾਦ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ: ਘਰੇਲੂ ਰਾਊਟਰ ਇਸ ਸਬਨੈੱਟ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ VPN ਇਹਨਾਂ ਸਬਨੈੱਟਾਂ ਨੂੰ ਕਲੱਸਟਰ ਤੋਂ ਕਲਾਇੰਟ ਤੱਕ ਧੱਕਦਾ ਹੈ।
• ਸਾਡੇ ਕੋਲ ਕਈ ਕਲੱਸਟਰ ਹਨ (ਉਤਪਾਦਨ, ਪੜਾਅ ਅਤੇ/ਜਾਂ ਕਈ ਦੇਵ ਕਲੱਸਟਰ)। ਫਿਰ, ਮੂਲ ਰੂਪ ਵਿੱਚ, ਉਹਨਾਂ ਸਾਰਿਆਂ ਕੋਲ ਪੌਡ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ ਇੱਕੋ ਜਿਹੇ ਸਬਨੈੱਟ ਹੋਣਗੇ, ਜੋ ਕਈ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਕੰਮ ਕਰਨ ਲਈ ਬਹੁਤ ਮੁਸ਼ਕਲਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।

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

ਅਤੇ ਫਿਰ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਪੁੱਛਿਆ: ਮੌਜੂਦਾ ਕਲੱਸਟਰ ਵਿੱਚ ਸਬਨੈੱਟ ਨੂੰ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ?

ਫੈਸਲਿਆਂ ਦੀ ਖੋਜ

ਸਭ ਤੋਂ ਆਮ ਅਭਿਆਸ ਮੁੜ ਬਣਾਉਣਾ ਹੈ ਸਾਰੇ ClusterIP ਕਿਸਮ ਨਾਲ ਸੇਵਾਵਾਂ। ਇੱਕ ਵਿਕਲਪ ਦੇ ਤੌਰ ਤੇ, ਸਲਾਹ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਇਹ:

ਨਿਮਨਲਿਖਤ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਹਰ ਚੀਜ਼ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, /etc/resolv.conf ਵਿੱਚ ਇੱਕ DNS ਨੇਮਸਰਵਰ ਵਜੋਂ ਪੌਡ ਪੁਰਾਣੇ IP ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ।
ਕਿਉਂਕਿ ਮੈਨੂੰ ਅਜੇ ਵੀ ਹੱਲ ਨਹੀਂ ਮਿਲਿਆ, ਮੈਨੂੰ kubeadm ਰੀਸੈਟ ਨਾਲ ਪੂਰੇ ਕਲੱਸਟਰ ਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਪਿਆ ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪਿਆ।

ਪਰ ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ... ਸਾਡੇ ਕੇਸ ਲਈ ਇੱਥੇ ਵਧੇਰੇ ਵਿਸਥਾਰਪੂਰਵਕ ਜਾਣ-ਪਛਾਣ ਹਨ:

• ਫਲੈਨਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ;
• ਬੱਦਲਾਂ ਅਤੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਦੋਵੇਂ ਕਲੱਸਟਰ ਹਨ;
• ਮੈਂ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਮੁੜ-ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਬਚਣਾ ਚਾਹਾਂਗਾ;
• ਆਮ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਸਮੱਸਿਆਵਾਂ ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ;
• Kubernetes ਸੰਸਕਰਣ 1.16.6 ਹੈ (ਹਾਲਾਂਕਿ, ਅਗਲੇ ਕਦਮ ਦੂਜੇ ਸੰਸਕਰਣਾਂ ਲਈ ਸਮਾਨ ਹੋਣਗੇ);
• ਮੁੱਖ ਕੰਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਇੱਕ ਸੇਵਾ ਸਬਨੈੱਟ ਨਾਲ kubeadm ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ 192.168.0.0/16, ਨਾਲ ਬਦਲੋ 172.24.0.0/16.

ਅਤੇ ਅਜਿਹਾ ਹੀ ਹੋਇਆ ਕਿ ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇਹ ਦੇਖਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਸੀ ਕਿ ਕੁਬਰਨੇਟਸ ਆਦਿ ਵਿੱਚ ਕੀ ਅਤੇ ਕਿਵੇਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਨਾਲ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ... ਇਸ ਲਈ ਅਸੀਂ ਸੋਚਿਆ: "ਕਿਉਂ ਨਾ ਸਿਰਫ etcd ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਅਪਡੇਟ ਕਰੋ, ਪੁਰਾਣੇ IP ਐਡਰੈੱਸ (ਸਬਨੈੱਟ) ਨੂੰ ਨਵੇਂ ਨਾਲ ਬਦਲੋ? "

etcd ਵਿੱਚ ਡੇਟਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ ਟੂਲਸ ਦੀ ਖੋਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਮਿਲੀ ਜਿਸ ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਹੋ ਗਿਆ ਹੋਵੇ। (ਵੈਸੇ, ਜੇਕਰ ਤੁਸੀਂ etcd ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕਿਸੇ ਉਪਯੋਗਤਾ ਬਾਰੇ ਜਾਣਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਲਿੰਕਾਂ ਦੀ ਸ਼ਲਾਘਾ ਕਰਾਂਗੇ।) ਹਾਲਾਂਕਿ, ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ ਆਦਿ ਸਹਾਇਕ OpenShift ਤੋਂ (ਇਸ ਦੇ ਲੇਖਕਾਂ ਦਾ ਧੰਨਵਾਦ!).

ਇਹ ਸਹੂਲਤ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ etcd ਨਾਲ ਜੁੜ ਸਕਦੀ ਹੈ ਅਤੇ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉੱਥੋਂ ਡਾਟਾ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ls, get, dump.

ਆਦਿ ਸਹਾਇਕ ਸ਼ਾਮਲ ਕਰੋ

ਅਗਲਾ ਵਿਚਾਰ ਤਰਕਪੂਰਨ ਹੈ: "ਕੀ ਤੁਹਾਨੂੰ etcd ਵਿੱਚ ਡੇਟਾ ਲਿਖਣ ਦੀ ਯੋਗਤਾ ਨੂੰ ਜੋੜ ਕੇ ਇਸ ਉਪਯੋਗਤਾ ਨੂੰ ਜੋੜਨ ਤੋਂ ਰੋਕ ਰਿਹਾ ਹੈ?"

ਇਹ ਦੋ ਨਵੇਂ ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਲ etcdhelper ਦਾ ਇੱਕ ਸੋਧਿਆ ਸੰਸਕਰਣ ਬਣ ਗਿਆ changeServiceCIDR и changePodCIDR. ਉਸ 'ਤੇ ਤੁਸੀਂ ਕੋਡ ਦੇਖ ਸਕਦੇ ਹੋ ਇੱਥੇ.

ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੀ ਕਰਦੀਆਂ ਹਨ? ਐਲਗੋਰਿਦਮ changeServiceCIDR:

• ਇੱਕ ਡੀਸੀਰੀਅਲਾਈਜ਼ਰ ਬਣਾਓ;
• CIDR ਨੂੰ ਬਦਲਣ ਲਈ ਇੱਕ ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਕੰਪਾਇਲ ਕਰੋ;
• ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ClusterIP ਕਿਸਮ ਦੀਆਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਾਂ:
  • etcd ਤੋਂ ਇੱਕ ਗੋ ਆਬਜੈਕਟ ਵਿੱਚ ਮੁੱਲ ਨੂੰ ਡੀਕੋਡ ਕਰੋ;
  • ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਪਤੇ ਦੇ ਪਹਿਲੇ ਦੋ ਬਾਈਟਾਂ ਨੂੰ ਬਦਲਦੇ ਹਾਂ;
  • ਸੇਵਾ ਨੂੰ ਨਵੇਂ ਸਬਨੈੱਟ ਤੋਂ ਇੱਕ IP ਪਤਾ ਨਿਰਧਾਰਤ ਕਰੋ;
  • ਇੱਕ ਸੀਰੀਅਲਾਈਜ਼ਰ ਬਣਾਓ, ਗੋ ਆਬਜੈਕਟ ਨੂੰ ਪ੍ਰੋਟੋਬਫ ਵਿੱਚ ਬਦਲੋ, etcd ਵਿੱਚ ਨਵਾਂ ਡੇਟਾ ਲਿਖੋ।

ਫੰਕਸ਼ਨ changePodCIDR ਅਸਲ ਵਿੱਚ ਸਮਾਨ changeServiceCIDR - ਸਿਰਫ ਸੇਵਾ ਨਿਰਧਾਰਨ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇਸਨੂੰ ਨੋਡ ਅਤੇ ਤਬਦੀਲੀ ਲਈ ਕਰਦੇ ਹਾਂ .spec.PodCIDR ਇੱਕ ਨਵੇਂ ਸਬਨੈੱਟ ਲਈ.

ਪ੍ਰੈਕਟਿਸ

ਸੇਵਾ CIDR ਬਦਲੋ

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

ਤਿਆਰੀ ਦੇ ਕਦਮ:

• ਲੋੜੀਂਦੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਅਤੇ ਪੈਚ ਕੀਤੇ ਆਦਿ ਸਹਾਇਕ ਨੂੰ ਜੋੜਨਾ;
• ਬੈਕਅੱਪ ਆਦਿ ਅਤੇ /etc/kubernetes.

ਸਰਵਿਸ ਸੀਆਈਡੀਆਰ ਨੂੰ ਬਦਲਣ ਲਈ ਸੰਖੇਪ ਕਾਰਜ ਯੋਜਨਾ:

• apiserver ਅਤੇ ਕੰਟਰੋਲਰ-ਪ੍ਰਬੰਧਕ ਮੈਨੀਫੈਸਟ ਨੂੰ ਬਦਲਣਾ;
• ਸਰਟੀਫਿਕੇਟ ਮੁੜ ਜਾਰੀ ਕਰਨਾ;
• ClusterIP ਸੇਵਾਵਾਂ ਨੂੰ etcd ਵਿੱਚ ਬਦਲਣਾ;
• ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੀਆਂ ਪੌਡਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ।

ਹੇਠਾਂ ਵੇਰਵੇ ਵਿੱਚ ਕਾਰਵਾਈਆਂ ਦਾ ਇੱਕ ਪੂਰਾ ਕ੍ਰਮ ਹੈ.

1. ਡਾਟਾ ਡੰਪ ਲਈ etcd-client ਇੰਸਟਾਲ ਕਰੋ:

apt install etcd-client

2. ਆਦਿ ਸਹਾਇਕ ਬਣਾਓ:

• ਗੋਲੰਗ ਸਥਾਪਿਤ ਕਰੋ:

  GOPATH=/root/golang
  mkdir -p $GOPATH/local
  curl -sSL https://dl.google.com/go/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH/local
  echo "export GOPATH="$GOPATH"" >> ~/.bashrc
  echo 'export GOROOT="$GOPATH/local/go"' >> ~/.bashrc
  echo 'export PATH="$PATH:$GOPATH/local/go/bin"' >> ~/.bashrc

• ਅਸੀਂ ਆਪਣੇ ਲਈ ਬਚਾਉਂਦੇ ਹਾਂ etcdhelper.go, ਨਿਰਭਰਤਾ ਡਾਊਨਲੋਡ ਕਰੋ, ਇਕੱਠਾ ਕਰੋ:

  wget https://raw.githubusercontent.com/flant/examples/master/2020/04-etcdhelper/etcdhelper.go
  go get go.etcd.io/etcd/clientv3 k8s.io/kubectl/pkg/scheme k8s.io/apimachinery/pkg/runtime
  go build -o etcdhelper etcdhelper.go

3. ਬੈਕਅੱਪ ਆਦਿ ਬਣਾਓ:

backup_dir=/root/backup
mkdir ${backup_dir}
cp -rL /etc/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --endpoints https://192.168.199.100:2379 snapshot save ${backup_dir}/etcd.snapshot

4. ਕੁਬਰਨੇਟਸ ਕੰਟਰੋਲ ਪਲੇਨ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਸਰਵਿਸ ਸਬਨੈੱਟ ਬਦਲੋ। ਫਾਈਲਾਂ ਵਿੱਚ /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml ਪੈਰਾਮੀਟਰ ਬਦਲੋ --service-cluster-ip-range ਇੱਕ ਨਵੇਂ ਸਬਨੈੱਟ ਲਈ: 172.24.0.0/16 ਦੀ ਬਜਾਏ 192.168.0.0/16.

5. ਕਿਉਂਕਿ ਅਸੀਂ ਸੇਵਾ ਸਬਨੈੱਟ ਨੂੰ ਬਦਲ ਰਹੇ ਹਾਂ ਜਿਸ ਵਿੱਚ kubeadm apiserver (ਸਮੇਤ) ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

1. ਆਓ ਦੇਖੀਏ ਕਿ ਮੌਜੂਦਾ ਸਰਟੀਫਿਕੇਟ ਕਿਸ ਡੋਮੇਨ ਅਤੇ IP ਪਤਿਆਂ ਲਈ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਹੈ:

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

2. ਆਓ kubeadm ਲਈ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਸੰਰਚਨਾ ਤਿਆਰ ਕਰੀਏ:

   cat kubeadm-config.yaml
   apiVersion: kubeadm.k8s.io/v1beta1
   kind: ClusterConfiguration
   networking:
     podSubnet: "10.244.0.0/16"
     serviceSubnet: "172.24.0.0/16"
   apiServer:
     certSANs:
     - "192.168.199.100" # IP-адрес мастер узла

3. ਚਲੋ ਪੁਰਾਣੀ ਸੀਆਰਟੀ ਅਤੇ ਕੁੰਜੀ ਨੂੰ ਮਿਟਾ ਦੇਈਏ, ਕਿਉਂਕਿ ਇਸ ਤੋਂ ਬਿਨਾਂ ਨਵਾਂ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ:

   rm /etc/kubernetes/pki/apiserver.{key,crt}

4. ਚਲੋ API ਸਰਵਰ ਲਈ ਸਰਟੀਫਿਕੇਟ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰੀਏ:

   kubeadm init phase certs apiserver --config=kubeadm-config.yaml

5. ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਸਰਟੀਫਿਕੇਟ ਨਵੇਂ ਸਬਨੈੱਟ ਲਈ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ:

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

6. API ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਮੁੜ-ਜਾਰੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਸਦੇ ਕੰਟੇਨਰ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ:

   docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

7. ਲਈ ਸੰਰਚਨਾ ਨੂੰ ਮੁੜ ਤਿਆਰ ਕਰੀਏ admin.conf:

   kubeadm alpha certs renew admin.conf

8. ਆਉ etcd ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੀਏ:

   ./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-service-cidr 172.24.0.0/16 

   ਸਾਵਧਾਨ ਇਸ ਸਮੇਂ, ਡੋਮੇਨ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਕਲੱਸਟਰ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਪੌਡ ਵਿੱਚ /etc/resolv.conf ਪੁਰਾਣਾ CoreDNS ਪਤਾ (kube-dns) ਰਜਿਸਟਰਡ ਹੈ, ਅਤੇ kube-proxy iptables ਨਿਯਮਾਂ ਨੂੰ ਪੁਰਾਣੇ ਸਬਨੈੱਟ ਤੋਂ ਨਵੇਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ ਲੇਖ ਵਿਚ ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਦੇ ਸੰਭਾਵੀ ਵਿਕਲਪਾਂ ਬਾਰੇ ਲਿਖਿਆ ਗਿਆ ਹੈ।

9. ਆਉ ਨੇਮਸਪੇਸ ਵਿੱਚ ConfigMap's ਨੂੰ ਠੀਕ ਕਰੀਏ kube-system:

   kubectl -n kube-system edit cm kubelet-config-1.16

   - ਇੱਥੇ ਬਦਲੋ clusterDNS kube-dns ਸੇਵਾ ਦੇ ਨਵੇਂ IP ਪਤੇ 'ਤੇ: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - ਅਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰਾਂਗੇ data.ClusterConfiguration.networking.serviceSubnet ਇੱਕ ਨਵੇਂ ਸਬਨੈੱਟ ਲਈ.

10. ਕਿਉਂਕਿ kube-dns ਐਡਰੈੱਸ ਬਦਲ ਗਿਆ ਹੈ, ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ kubelet ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ:

    kubeadm upgrade node phase kubelet-config && systemctl restart kubelet

11. ਜੋ ਕੁਝ ਬਚਿਆ ਹੈ ਉਹ ਹੈ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੀਆਂ ਪੌਡਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ:

    kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'

ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰੋ

ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਬਾਰੇ ਵਿਚਾਰ:

1. ਕੰਟਰੋਲ ਪਲੇਨ ਮੈਨੀਫੈਸਟ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਨਵੀਂ kube-dns ਸੇਵਾ ਬਣਾਓ, ਉਦਾਹਰਨ ਲਈ, ਨਾਮ ਦੇ ਨਾਲ kube-dns-tmp ਅਤੇ ਨਵਾਂ ਪਤਾ 172.24.0.10.
2. ਬਣਾਉਣ ਲਈ if etcdhelper ਵਿੱਚ, ਜੋ ਕਿ kube-dns ਸੇਵਾ ਨੂੰ ਸੰਸ਼ੋਧਿਤ ਨਹੀਂ ਕਰੇਗਾ।
3. ਸਾਰੇ ਕੁਬੇਲੇਟਾਂ ਵਿੱਚ ਪਤਾ ਬਦਲੋ ClusterDNS ਨਵੀਂ ਸੇਵਾ ਲਈ, ਜਦੋਂ ਕਿ ਪੁਰਾਣੀ ਸੇਵਾ ਨਵੀਂ ਦੇ ਨਾਲ ਨਾਲ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗੀ।
4. ਉਦੋਂ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕਰੋ ਜਦੋਂ ਤੱਕ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਾਲੇ ਪੌਡ ਜਾਂ ਤਾਂ ਕੁਦਰਤੀ ਕਾਰਨਾਂ ਕਰਕੇ ਜਾਂ ਇੱਕ ਸਹਿਮਤ ਸਮੇਂ 'ਤੇ ਆਪਣੇ ਆਪ ਰੋਲ ਨਹੀਂ ਹੋ ਜਾਂਦੇ।
5. ਸੇਵਾ ਮਿਟਾਓ kube-dns-tmp ਅਤੇ ਬਦਲੋ serviceSubnetCIDR kube-dns ਸੇਵਾ ਲਈ।

ਇਹ ਯੋਜਨਾ ਤੁਹਾਨੂੰ ਡਾਊਨਟਾਈਮ ਨੂੰ ~ ਇੱਕ ਮਿੰਟ ਤੱਕ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗੀ - ਸੇਵਾ ਹਟਾਉਣ ਦੀ ਮਿਆਦ ਲਈ kube-dns-tmp ਅਤੇ ਸੇਵਾ ਲਈ ਸਬਨੈੱਟ ਨੂੰ ਬਦਲਣਾ kube-dns.

ਸੋਧ podNetwork

ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਨਤੀਜੇ ਵਾਲੇ etcdhelper ਦੀ ਵਰਤੋਂ ਕਰਕੇ podNetwork ਨੂੰ ਕਿਵੇਂ ਸੋਧਿਆ ਜਾਵੇ। ਕਾਰਵਾਈਆਂ ਦਾ ਕ੍ਰਮ ਇਸ ਪ੍ਰਕਾਰ ਹੈ:

• ਵਿੱਚ ਸੰਰਚਨਾ ਫਿਕਸਿੰਗ kube-system;
• kube-controller-manager ਮੈਨੀਫੈਸਟ ਨੂੰ ਠੀਕ ਕਰਨਾ;
• podCIDR ਨੂੰ ਸਿੱਧਾ etcd ਵਿੱਚ ਬਦਲੋ;
• ਸਾਰੇ ਕਲੱਸਟਰ ਨੋਡ ਰੀਬੂਟ ਕਰੋ।

ਹੁਣ ਇਹਨਾਂ ਕਾਰਵਾਈਆਂ ਬਾਰੇ ਹੋਰ:

1. ਨੇਮਸਪੇਸ ਵਿੱਚ ConfigMaps ਨੂੰ ਸੋਧੋ kube-system:

kubectl -n kube-system edit cm kubeadm-config

- ਠੀਕ ਕਰਨਾ data.ClusterConfiguration.networking.podSubnet ਇੱਕ ਨਵੇਂ ਸਬਨੈੱਟ ਲਈ 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- ਠੀਕ ਕਰਨਾ data.config.conf.clusterCIDR: 10.55.0.0/16.

2. ਕੰਟਰੋਲਰ-ਪ੍ਰਬੰਧਕ ਮੈਨੀਫੈਸਟ ਨੂੰ ਸੋਧੋ:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

- ਠੀਕ ਕਰਨਾ --cluster-cidr=10.55.0.0/16.

3. ਮੌਜੂਦਾ ਮੁੱਲਾਂ ਨੂੰ ਦੇਖੋ .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses ਸਾਰੇ ਕਲੱਸਟਰ ਨੋਡਾਂ ਲਈ:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. ਸਿੱਧੇ etcd ਵਿੱਚ ਬਦਲਾਅ ਕਰਕੇ podCIDR ਨੂੰ ਬਦਲੋ:

./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-pod-cidr 10.55.0.0/16

5. ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਪੌਡਸੀਆਈਡੀਆਰ ਅਸਲ ਵਿੱਚ ਬਦਲ ਗਿਆ ਹੈ:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. ਆਉ ਇੱਕ ਇੱਕ ਕਰਕੇ ਸਾਰੇ ਕਲੱਸਟਰ ਨੋਡਸ ਨੂੰ ਰੀਬੂਟ ਕਰੀਏ।

7. ਜੇਕਰ ਤੁਸੀਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਨੋਡ ਛੱਡਦੇ ਹੋ ਪੁਰਾਣਾ ਪੋਡਸੀਆਈਡੀਆਰ, ਫਿਰ kube-controller-manager ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਕਲੱਸਟਰ ਵਿੱਚ ਪੌਡਾਂ ਨੂੰ ਨਿਯਤ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਵਾਸਤਵ ਵਿੱਚ, ਪੌਡਸੀਆਈਡੀਆਰ ਨੂੰ ਬਦਲਣਾ ਹੋਰ ਵੀ ਸਰਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇਸ ਲਈ). ਪਰ ਅਸੀਂ ਇਹ ਸਿੱਖਣਾ ਚਾਹੁੰਦੇ ਸੀ ਕਿ etcd ਨਾਲ ਸਿੱਧੇ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਕਿਉਂਕਿ ਅਜਿਹੇ ਕੇਸ ਹੁੰਦੇ ਹਨ ਜਦੋਂ etcd ਵਿੱਚ Kubernetes ਆਬਜੈਕਟ ਨੂੰ ਸੰਪਾਦਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਕੇਵਲ ਇਕੋ ਸੰਭਵ ਰੂਪ. (ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਦੇ ਸੇਵਾ ਖੇਤਰ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦੇ spec.clusterIP.)

ਨਤੀਜਾ

ਲੇਖ ਸਿੱਧੇ etcd ਵਿੱਚ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਬਾਰੇ ਚਰਚਾ ਕਰਦਾ ਹੈ, i.e. Kubernetes API ਨੂੰ ਛੱਡ ਕੇ। ਕਈ ਵਾਰੀ ਇਹ ਪਹੁੰਚ ਤੁਹਾਨੂੰ "ਛਲਦਾਰ ਚੀਜ਼ਾਂ" ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਅਸੀਂ ਅਸਲ K8s ਕਲੱਸਟਰਾਂ 'ਤੇ ਟੈਕਸਟ ਵਿੱਚ ਦਿੱਤੇ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਹਾਲਾਂਕਿ, ਵਿਆਪਕ ਵਰਤੋਂ ਲਈ ਉਹਨਾਂ ਦੀ ਤਿਆਰੀ ਦੀ ਸਥਿਤੀ ਹੈ PoC (ਸੰਕਲਪ ਦਾ ਸਬੂਤ). ਇਸ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਕਲੱਸਟਰਾਂ 'ਤੇ etcdhelper ਉਪਯੋਗਤਾ ਦੇ ਸੋਧੇ ਹੋਏ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਅਜਿਹਾ ਆਪਣੇ ਜੋਖਮ 'ਤੇ ਕਰੋ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «etcd 3.4.3: ਸਟੋਰੇਜ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਅਧਿਐਨ";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਕੈਲੀਕੋ: ਜਾਣ-ਪਛਾਣ ਅਤੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਅਨੁਭਵ";
• «ਕੁਬਰਨੇਟਸ [ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ] ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ 6 ਮਨੋਰੰਜਕ ਸਿਸਟਮ ਬੱਗ";
• «ਕੁਬਰਨੇਟਸ ਦੇ ਨਿਪਟਾਰੇ ਲਈ ਇੱਕ ਵਿਜ਼ੂਅਲ ਗਾਈਡ".

ਸਰੋਤ: www.habr.com