ಕುಬರ್ನೆಟ್ಸ್ನ ಸರಿಯಾದ ಹೋಲಿಕೆ ಅನ್ವಯಿಸಿ, ಬದಲಿಸಿ ಮತ್ತು ಪ್ಯಾಚ್ ಮಾಡಿ

ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಹಲವಾರು ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದೆ: ಅನ್ವಯಿಸಿ, ಸಂಪಾದಿಸಿ, ಪ್ಯಾಚ್ ಮಾಡಿ ಮತ್ತು ಬದಲಾಯಿಸಿ. ಪ್ರತಿಯೊಬ್ಬರೂ ಏನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಯಾವಾಗ ಬಳಸಬೇಕು ಎಂಬ ಗೊಂದಲವಿದೆ. ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.

ವೇಳೆ Google ನಲ್ಲಿ ಹುಡುಕಿ "ಕುಬರ್ನೆಟ್ಸ್ ಅಪ್ಲೈ ವರ್ಸಸ್ ರಿಪ್ಲೇಸ್" ಎಂಬ ನುಡಿಗಟ್ಟು ಇದೆ StackOverflow ಗೆ ಪ್ರತ್ಯುತ್ತರ ನೀಡಿ, ಇದು ಸರಿಯಾಗಿಲ್ಲ. ಹುಡುಕುವಾಗ "ಕುಬರ್ನೆಟ್ಸ್ ಅಪ್ಲೈ ವರ್ಸಸ್ ಪ್ಯಾಚ್" ಮೊದಲ ಲಿಂಕ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಆಗಿದೆ kubectl patch, ಇದು ಹೋಲಿಕೆಯನ್ನು ಒಳಗೊಂಡಿಲ್ಲ apply и patch. ಈ ಲೇಖನವು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳನ್ನು ಮತ್ತು ಪ್ರತಿಯೊಂದರ ಸರಿಯಾದ ಬಳಕೆಯನ್ನು ನೋಡುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲದ ಜೀವನಚಕ್ರದ ಸಮಯದಲ್ಲಿ (ಸೇವೆ, ನಿಯೋಜನೆ, ಪ್ರವೇಶ, ಇತ್ಯಾದಿ), ಕೆಲವೊಮ್ಮೆ ನೀವು ಈ ಸಂಪನ್ಮೂಲದ ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕು, ಸೇರಿಸಬೇಕು ಅಥವಾ ತೆಗೆದುಹಾಕಬೇಕು. ಉದಾಹರಣೆಗೆ, ಟಿಪ್ಪಣಿಯನ್ನು ಸೇರಿಸಿ, ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿ ಅಥವಾ ಕಡಿಮೆ ಮಾಡಿ.

ಕುಬರ್ನೆಟ್ಸ್ CLI

ನೀವು ಈಗಾಗಲೇ CLI ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಈಗಾಗಲೇ ಪರಿಚಿತರಾಗಿರುವಿರಿ apply и edit. ತಂಡ apply ಫೈಲ್‌ನಿಂದ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ "ಅಪ್ಸರ್ಟ್" ಮಾಡುತ್ತದೆ, ಅಂದರೆ. ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ಅದನ್ನು ನವೀಕರಿಸುತ್ತದೆ. ತಂಡ edit API ಮೂಲಕ ಸಂಪನ್ಮೂಲವನ್ನು ಓದುತ್ತದೆ, ನಂತರ ಸ್ಥಳೀಯ ಫೈಲ್‌ಗೆ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯನ್ನು ಬರೆಯುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಪಠ್ಯ ಸಂಪಾದಕದಲ್ಲಿ ತೆರೆಯಲಾಗುತ್ತದೆ. ನೀವು ಫೈಲ್ ಅನ್ನು ಸಂಪಾದಿಸಿ ಮತ್ತು ಉಳಿಸಿದ ನಂತರ, kubectl API ಮೂಲಕ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ಮರಳಿ ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಸಂಪನ್ಮೂಲಕ್ಕೆ ಈ ಬದಲಾವಣೆಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಅನ್ವಯಿಸುತ್ತದೆ.

ಎಲ್ಲರಿಗೂ ಆಜ್ಞೆಗಳು ತಿಳಿದಿಲ್ಲ patch и replace. ತಂಡ patch ಆಜ್ಞಾ ಸಾಲಿನಲ್ಲಿ ಬದಲಾದ ಭಾಗವನ್ನು ಮಾತ್ರ ಒದಗಿಸುವ ಮೂಲಕ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯ ಭಾಗವನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ತಂಡ replace ಅದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ edit, ಆದರೆ ಎಲ್ಲವನ್ನೂ ಕೈಯಾರೆ ಮಾಡಬೇಕಾಗಿದೆ: ನೀವು ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಬಳಸಿ kubectl get -o yaml, ಅದನ್ನು ಸಂಪಾದಿಸಿ, ನಂತರ ಬಳಸಿ replace ಬದಲಾದ ನಿರ್ದಿಷ್ಟತೆಯ ಪ್ರಕಾರ ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸಲು. ತಂಡ replace ಸಂಪನ್ಮೂಲವನ್ನು ಓದುವ ಮತ್ತು ಬದಲಿಸುವ ನಡುವೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ಕುಬರ್ನೆಟ್ಸ್ API

ನೀವು ಬಹುಶಃ ವಿಧಾನಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದೀರಿ CoreV1().Pods().Update(), replaceNamespacedService ಅಥವಾ patch_namespaced_deployment, ನೀವು ಕ್ಲಸ್ಟರ್‌ಗಳ ಮೂಲಕ ಕೆಲಸ ಮಾಡಿದರೆ ಕುಬರ್ನೆಟ್ಸ್ API ಗಾಗಿ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ ಕೆಲವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಬಳಸುವುದು. ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು HTTP ವಿನಂತಿಗಳ ಮೂಲಕ ಗ್ರಂಥಾಲಯವು ಈ ವಿಧಾನಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ PUT и PATCH... ಇದರಲ್ಲಿ update и replace ಬಳಕೆ PUTಮತ್ತು patch, ಅದು ಎಷ್ಟೇ ಕ್ಷುಲ್ಲಕವಾಗಿದ್ದರೂ, ಬಳಸುತ್ತದೆ PATCH.

ಇದು ಗಮನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿದೆ kubectl API ಮೂಲಕ ಕ್ಲಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಬೇರೆ ಪದಗಳಲ್ಲಿ, kubectlಗೋ ಭಾಷೆಗಾಗಿ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯ ಮೇಲ್ಭಾಗದ ಹೊದಿಕೆಯಾಗಿದೆ, ಇದು ಪ್ರಮಾಣಿತ API ಸಾಮರ್ಥ್ಯಗಳ ಜೊತೆಗೆ ಹೆಚ್ಚು ಸಾಂದ್ರವಾದ ಮತ್ತು ಓದಬಲ್ಲ ರೂಪದಲ್ಲಿ ಉಪಕಮಾಂಡ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೆಚ್ಚಾಗಿ ಒದಗಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಈಗಾಗಲೇ ಗಮನಿಸಿದಂತೆ, ವಿಧಾನ apply ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ಮೇಲೆ ಉಲ್ಲೇಖಿಸಲಾಗಿಲ್ಲ. ಪ್ರಸ್ತುತ (ಮೇ 2020, ಅಂದಾಜು ಅನುವಾದಕ) ಎಲ್ಲಾ ತರ್ಕ kubectl apply, ಅಂದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ನವೀಕರಿಸುವುದು, ಸಂಪೂರ್ಣವಾಗಿ ಕೋಡ್ ಬದಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ kubectl. ಪ್ರಯತ್ನಗಳು ನಡೆಯುತ್ತಿವೆ ತರ್ಕ ವರ್ಗಾವಣೆಯ ಮೇಲೆ apply API ಬದಿಗೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಬೀಟಾದಲ್ಲಿದೆ. ನಾನು ಕೆಳಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಬರೆಯುತ್ತೇನೆ.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪ್ಯಾಚ್ ಮಾಡಿ

ಉತ್ತಮವಾಗಿ ಬಳಸಲಾಗಿದೆ patch, ನೀವು ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸಲು ಬಯಸಿದರೆ. ಎರಡೂ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳು ಕುಬರ್ನೆಟ್ಸ್ API ಮತ್ತು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ kubectl (ಆಶ್ಚರ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗೆ ಹೊದಿಕೆಯಾಗಿದೆ, ಅಂದಾಜು ಅನುವಾದಕ).

ಕಾರ್ಯತಂತ್ರವಾಗಿ ಕೆಲಸ ಮಾಡಿ

ಎಲ್ಲಾ ತಂಡಗಳು kubectl apply, edit и patch ವಿಧಾನವನ್ನು ಬಳಸಿ PATCH ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸಲು HTTP ವಿನಂತಿಗಳಲ್ಲಿ. ನೀವು ಆಜ್ಞೆಗಳ ಅನುಷ್ಠಾನವನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸಿದರೆ, ಅವರೆಲ್ಲರೂ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತಾರೆ ಕಾರ್ಯತಂತ್ರ-ವಿಲೀನ ಪ್ಯಾಚಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸಲು, ಆದಾಗ್ಯೂ ಆಜ್ಞೆ patch ಇತರ ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು (ಇದರ ಬಗ್ಗೆ ಕೆಳಗೆ). ಕಾರ್ಯತಂತ್ರದ-ವಿಲೀನ ಪ್ಯಾಚಿಂಗ್ ವಿಧಾನವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿವರಣೆಯೊಂದಿಗೆ ಸರಬರಾಜು ಮಾಡಿದ ವಿವರಣೆಯನ್ನು ವಿಲೀನಗೊಳಿಸುವ ಮೂಲಕ "ಅದನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯಲು" ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಆಬ್ಜೆಕ್ಟ್ಸ್ ಮತ್ತು ಅರೇ ಎರಡನ್ನೂ ಸಂಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಅಂದರೆ ಬದಲಾವಣೆಗಳು ಸಂಯೋಜಕವಾಗಿರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವುದು patch ಪಾಡ್ ಕಂಟೇನರ್ ವಿವರಣೆಯಲ್ಲಿ ಹೊಸ ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ನೊಂದಿಗೆ, ಪರಿಸರ ವೇರಿಯೇಬಲ್ ಅನ್ನು ತಿದ್ದಿ ಬರೆಯುವ ಬದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಸೇರಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. ಈ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ತೆಗೆದುಹಾಕಲು, ನೀವು ಒದಗಿಸಿದ ವಿವರಣೆಯಲ್ಲಿ ನಿಯತಾಂಕ ಮೌಲ್ಯವನ್ನು ಶೂನ್ಯಕ್ಕೆ ಒತ್ತಾಯಿಸಬೇಕು. ಯಾವ ತಂಡಗಳು kubectl ನವೀಕರಿಸಲು ಬಳಸುವುದು ಉತ್ತಮವೇ?

ಬಳಸಿ ನಿಮ್ಮ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀವು ರಚಿಸಿದರೆ ಮತ್ತು ನಿರ್ವಹಿಸಿದರೆ kubectl apply, ನವೀಕರಿಸುವಾಗ ಯಾವಾಗಲೂ ಬಳಸುವುದು ಉತ್ತಮ kubectl applyಗೆ kubectl ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ವಿನಂತಿಸಿದ ಬದಲಾವಣೆಗಳನ್ನು ಸರಿಯಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಪ್ರಯೋಜನ ಯಾವಾಗಲೂ ಬಳಸಿ apply ಇದು ಹಿಂದೆ ಅನ್ವಯಿಸಲಾದ ವಿವರಣೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ರಚನೆಯ ಅಂಶಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಹಾಕಿದಾಗ ಅದನ್ನು ತಿಳಿಯಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದು ನಿಮಗೆ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ apply ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ರಚನೆಯ ಅಂಶಗಳನ್ನು ತೆಗೆದುಹಾಕಲು, ಸಾಮಾನ್ಯ ಕಾರ್ಯತಂತ್ರದ ವಿಲೀನವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ತಂಡಗಳು edit и patch ಟಿಪ್ಪಣಿಗಳನ್ನು ನವೀಕರಿಸಬೇಡಿ kubectl apply ಅದರ ಬದಲಾವಣೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕುಬರ್ನೆಟ್ಸ್ API ಮೂಲಕ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾದ ಮತ್ತು ಮಾಡಿದ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು, ಆದರೆ ಆಜ್ಞೆಗಳ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ edit и patch, ನಂತರದ ಆಜ್ಞೆಗಳಿಗೆ ಅಗೋಚರ apply, ಅಂದರೆ apply ಇನ್‌ಪುಟ್ ವಿವರಣೆಯಲ್ಲಿ ಕಾಣಿಸದಿದ್ದರೂ ಸಹ ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ apply (ದಸ್ತಾವೇಜನ್ನು ಹೇಳುತ್ತದೆ edit и patch ಬಳಸಿದ ಟಿಪ್ಪಣಿಗಳಿಗೆ ನವೀಕರಣಗಳನ್ನು ಮಾಡಿ apply, ಆದರೆ ಆಚರಣೆಯಲ್ಲಿ - ಇಲ್ಲ).

ನೀವು ಆಜ್ಞೆಯನ್ನು ಬಳಸದಿದ್ದರೆ apply, ಎಂದು ಬಳಸಬಹುದು edit, ಮತ್ತು patch, ಮಾಡಲಾದ ಬದಲಾವಣೆಗೆ ಸೂಕ್ತವಾದ ಆಜ್ಞೆಯನ್ನು ಆರಿಸುವುದು. BOM ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸೇರಿಸುವಾಗ ಮತ್ತು ಬದಲಾಯಿಸುವಾಗ, ಎರಡೂ ವಿಧಾನಗಳು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತವೆ. ನಿರ್ದಿಷ್ಟ ಗುಣಲಕ್ಷಣಗಳು ಅಥವಾ ರಚನೆಯ ಅಂಶಗಳನ್ನು ಅಳಿಸುವಾಗ edit ಒಂದು-ಬಾರಿ ಉಡಾವಣೆಯಂತೆ ವರ್ತಿಸುತ್ತದೆ apply, ಅದನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಮತ್ತು ನಂತರ ನಿರ್ದಿಷ್ಟತೆ ಹೇಗಿತ್ತು ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಸೇರಿದಂತೆ, ಆದ್ದರಿಂದ ನೀವು ಸಂಪನ್ಮೂಲದಿಂದ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ರಚನೆಯ ಅಂಶಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು. ನೀವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಆಸ್ತಿ ಮೌಲ್ಯವನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸುವ ಅಗತ್ಯವಿದೆ patchಅದನ್ನು ಸಂಪನ್ಮೂಲದಿಂದ ತೆಗೆದುಹಾಕಲು. ಸ್ಟ್ರಾಟೆಜಿಕ್-ಮರ್ಜ್ ಪ್ಯಾಚಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ರಚನೆಯ ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕುವುದು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಏಕೆಂದರೆ ಇದಕ್ಕೆ ವಿಲೀನ ನಿರ್ದೇಶನಗಳ ಬಳಕೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೆಚ್ಚು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಪರ್ಯಾಯಗಳಿಗಾಗಿ ಕೆಳಗಿನ ಇತರ ಅಪ್‌ಗ್ರೇಡ್ ವಿಧಾನಗಳನ್ನು ನೋಡಿ.

ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯಲ್ಲಿ ಅಪ್‌ಡೇಟ್ ವಿಧಾನಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮೇಲಿನ ಕಮಾಂಡ್‌ಗಳಂತೆಯೇ ವರ್ತಿಸುತ್ತದೆ kubectl, ವಿನಂತಿಗಳಲ್ಲಿ ಹೊಂದಿಸಬೇಕು content-type в application/strategic-merge-patch+json. ನೀವು ನಿರ್ದಿಷ್ಟತೆಯಲ್ಲಿ ಗುಣಲಕ್ಷಣಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಬಯಸಿದರೆ, ನೀವು ಅವುಗಳ ಮೌಲ್ಯಗಳನ್ನು ಇದೇ ರೀತಿಯಲ್ಲಿ ಶೂನ್ಯಕ್ಕೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ kubectl patch. ನೀವು ರಚನೆಯ ಅಂಶಗಳನ್ನು ತೆಗೆದುಹಾಕಬೇಕಾದರೆ, ನೀವು ನವೀಕರಣದ ವಿವರಣೆಯಲ್ಲಿ ವಿಲೀನ ನಿರ್ದೇಶನಗಳನ್ನು ಸೇರಿಸಬೇಕು ಅಥವಾ ನವೀಕರಣಗಳಿಗೆ ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ಬಳಸಬೇಕು.

ನವೀಕರಣಗಳಿಗೆ ಇತರ ವಿಧಾನಗಳು

ಕುಬರ್ನೆಟ್ಸ್ ಎರಡು ಇತರ ನವೀಕರಣ ವಿಧಾನಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ: JSON ವಿಲೀನ ಪ್ಯಾಚ್ и JSON ಪ್ಯಾಚ್. JSON ವಿಲೀನ ಪ್ಯಾಚ್ ವಿಧಾನವು ಭಾಗಶಃ Kubernetes ವಿವರಣೆಯನ್ನು ಇನ್‌ಪುಟ್ ಆಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯತಂತ್ರ-ವಿಲೀನ ಪ್ಯಾಚಿಂಗ್ ವಿಧಾನವನ್ನು ಹೋಲುವ ವಸ್ತುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಇದು ಪಾಡ್ ವಿವರಣೆಯಲ್ಲಿ ಕಂಟೇನರ್ ಅರೇ ಸೇರಿದಂತೆ ಅರೇ ಬದಲಿಯನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದರರ್ಥ JSON ವಿಲೀನ ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸುವಾಗ, ಯಾವುದೇ ಕಂಟೇನರ್‌ನ ಯಾವುದೇ ಗುಣಲಕ್ಷಣವು ಬದಲಾದರೆ ನೀವು ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ವಿಶೇಷಣಗಳನ್ನು ಒದಗಿಸಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಈ ವಿಧಾನವು BOM ನಲ್ಲಿನ ರಚನೆಯಿಂದ ಅಂಶಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಉಪಯುಕ್ತವಾಗಿದೆ. ಆಜ್ಞಾ ಸಾಲಿನಲ್ಲಿ ನೀವು JSON ವಿಲೀನ ಪ್ಯಾಚ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು kubectl patch --type=merge. ಕುಬರ್ನೆಟ್ಸ್ API ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ನೀವು ವಿನಂತಿಯ ವಿಧಾನವನ್ನು ಬಳಸಬೇಕು PATCH ಮತ್ತು ಅನುಸ್ಥಾಪನ content-type в application/merge-patch+json.

JSON ಪ್ಯಾಚ್ ವಿಧಾನವು ಸಂಪನ್ಮೂಲದ ಭಾಗಶಃ ವಿವರಣೆಯನ್ನು ಒದಗಿಸುವ ಬದಲು, ನೀವು ಸಂಪನ್ಮೂಲಕ್ಕೆ ಮಾಡಲು ಬಯಸುವ ಬದಲಾವಣೆಗಳನ್ನು ಒಂದು ಶ್ರೇಣಿಯಂತೆ ಬಳಸುತ್ತದೆ, ಇದರಲ್ಲಿ ರಚನೆಯ ಪ್ರತಿಯೊಂದು ಅಂಶವು ಸಂಪನ್ಮೂಲಕ್ಕೆ ಮಾಡಲಾದ ಬದಲಾವಣೆಯ ವಿವರಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಮಾಡಲಾದ ಬದಲಾವಣೆಗಳನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಶಕ್ತಿಯುತವಾದ ಮಾರ್ಗವಾಗಿದೆ, ಆದರೆ ಭಾಗಶಃ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯನ್ನು ಕಳುಹಿಸುವ ಬದಲು ಪ್ರತ್ಯೇಕವಾದ, ಕುಬರ್ನೆಟ್ಸ್ ಅಲ್ಲದ ಸ್ವರೂಪದಲ್ಲಿ ಮಾಡಲಾದ ಬದಲಾವಣೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ವೆಚ್ಚದಲ್ಲಿ. IN kubectl ನೀವು JSON ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಆಯ್ಕೆ ಮಾಡಬಹುದು kubectl patch --type=json. ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಬಳಸುವಾಗ, ಈ ವಿಧಾನವು ವಿನಂತಿಯ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ PATCH ಮತ್ತು ಅನುಸ್ಥಾಪನ content-type в application/json-patch+json.

ನಮಗೆ ಆತ್ಮವಿಶ್ವಾಸ ಬೇಕು - ಬದಲಿ ಬಳಸಿ

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಂಪನ್ಮೂಲವನ್ನು ಓದುವ ಸಮಯ ಮತ್ತು ಅದನ್ನು ನವೀಕರಿಸಿದ ಸಮಯದ ನಡುವೆ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಆಗುತ್ತವೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು ಪರಮಾಣು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಬಳಸಬೇಕಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸಲು replace. ಉದಾಹರಣೆಗೆ, ನೀವು ಬಹು ಮೂಲಗಳಿಂದ ಅಪ್‌ಡೇಟ್ ಮಾಡಲಾದ ಕೌಂಟರ್‌ನೊಂದಿಗೆ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಹೊಂದಿದ್ದರೆ, ಎರಡು ಮೂಲಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಕೌಂಟರ್ ಅನ್ನು ನವೀಕರಿಸುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ತಿಳಿದಿರಬೇಕು, ಇದರಿಂದಾಗಿ ನವೀಕರಣವು ಕಳೆದುಹೋಗುತ್ತದೆ. ಪ್ರದರ್ಶಿಸಲು, ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಘಟನೆಗಳ ಅನುಕ್ರಮವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ patch:

• A ಮತ್ತು B API ನಿಂದ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯುತ್ತವೆ
• ಪ್ರತಿಯೊಂದೂ ಸ್ಥಳೀಯವಾಗಿ ಕೌಂಟರ್ ಅನ್ನು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು "ಅಪ್‌ಡೇಟ್-ಬೈ" ಟಿಪ್ಪಣಿಗೆ ಕ್ರಮವಾಗಿ "A" ಅಥವಾ "B" ಅನ್ನು ಸೇರಿಸುತ್ತದೆ.
• ಮತ್ತು ಇದು ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವಲ್ಪ ವೇಗವಾಗಿ ನವೀಕರಿಸುತ್ತದೆ
• B ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸುತ್ತದೆ

ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಡೇಟ್ A ಕಳೆದುಹೋಗಿದೆ. ಕೊನೆಯ ಕಾರ್ಯಾಚರಣೆ patch ಗೆಲ್ಲುತ್ತದೆ, ಕೌಂಟರ್ ಅನ್ನು ಎರಡರ ಬದಲು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು "ಅಪ್‌ಡೇಟ್ ಮಾಡಲಾದ" ಟಿಪ್ಪಣಿಯ ಮೌಲ್ಯವು "B" ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು "A" ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ನವೀಕರಣಗಳನ್ನು ಮಾಡಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಜೊತೆಗೆ ಮೇಲಿನದನ್ನು ಹೋಲಿಸೋಣ replace:

• A ಮತ್ತು B API ನಿಂದ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯುತ್ತವೆ
• ಪ್ರತಿಯೊಂದೂ ಸ್ಥಳೀಯವಾಗಿ ಕೌಂಟರ್ ಅನ್ನು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು "ಅಪ್‌ಡೇಟ್-ಬೈ" ಟಿಪ್ಪಣಿಗೆ ಕ್ರಮವಾಗಿ "A" ಅಥವಾ "B" ಅನ್ನು ಸೇರಿಸುತ್ತದೆ.
• ಮತ್ತು ಇದು ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವಲ್ಪ ವೇಗವಾಗಿ ನವೀಕರಿಸುತ್ತದೆ
• B ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಆದರೆ API ನಿಂದ ನವೀಕರಣವನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಸಂಪನ್ಮೂಲ ಆವೃತ್ತಿಯು ವಿವರಣೆಯಲ್ಲಿದೆ replace ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ A ಯ ಬದಲಿ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಸಂಪನ್ಮೂಲದ ಆವೃತ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.

ಮೇಲಿನ ಸಂದರ್ಭದಲ್ಲಿ, B ಸಂಪನ್ಮೂಲವನ್ನು ಮರು-ಪಡೆಯಬೇಕು, ಹೊಸ ಸ್ಥಿತಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕು ಮತ್ತು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕು replace. ಇದು ಕೌಂಟರ್ ಅನ್ನು ಎರಡರಿಂದ ಹೆಚ್ಚಿಸಲು ಮತ್ತು "ಅಪ್‌ಡೇಟ್-ಬೈ" ಟಿಪ್ಪಣಿಯನ್ನು ಕೊನೆಯಲ್ಲಿ "AB" ಸೇರಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ.

ಮೇಲಿನ ಉದಾಹರಣೆಯು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಸೂಚಿಸುತ್ತದೆ replace ಸಂಪೂರ್ಣ ಸಂಪನ್ಮೂಲವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲಾಗಿದೆ. ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ಬಳಸಲಾಗಿದೆ replace, ಭಾಗಶಃ ಅಥವಾ ಭಾಗಗಳಾಗಿರಬಾರದು apply, ಆದರೆ ಸೇರ್ಪಡೆ ಸೇರಿದಂತೆ ಸಂಪೂರ್ಣ resourceVersion ನಿರ್ದಿಷ್ಟತೆಯ ಮೆಟಾಡೇಟಾದಲ್ಲಿ. ನೀವು ಸಕ್ರಿಯಗೊಳಿಸದಿದ್ದರೆ resourceVersion ಅಥವಾ ನೀವು ಒದಗಿಸಿದ ಆವೃತ್ತಿಯು ಪ್ರಸ್ತುತವಲ್ಲ, ಬದಲಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಬಳಸಲು ಉತ್ತಮ ವಿಧಾನವಾಗಿದೆ replace - ಸಂಪನ್ಮೂಲವನ್ನು ಓದಿ, ಅದನ್ನು ನವೀಕರಿಸಿ ಮತ್ತು ಅದನ್ನು ತಕ್ಷಣವೇ ಬದಲಾಯಿಸಿ. ಬಳಸಿ kubectl, ಇದು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

ಅನುಕ್ರಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ಕೆಳಗಿನ ಎರಡು ಆಜ್ಞೆಗಳು ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತವೆ ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. deployment.yaml ಆಸ್ತಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

ಇದು ಮೇಲೆ ಹೇಳಿದ್ದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ತೋರುತ್ತದೆ, ಅಂದರೆ. "ಸೇರಿಸುವುದು resourceVersion ನಿರ್ದಿಷ್ಟತೆಯ ಮೆಟಾಡೇಟಾದಲ್ಲಿ." ಹಾಗೆ ಹೇಳುವುದು ತಪ್ಪೇ? ಇಲ್ಲ, ಅದು ಅಲ್ಲ, ಏಕೆಂದರೆ ವೇಳೆ kubectl ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿರುವ ಸೂಚನೆಗಳು resourceVersion, ಇದು ಸಂಪನ್ಮೂಲದಿಂದ ಅದನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ವಿವರಣೆಗೆ ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ replace. ನೀವು ಪರಮಾಣುತ್ವವನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ ಇದು ಅಪಾಯಕಾರಿ ಏಕೆಂದರೆ, ಮ್ಯಾಜಿಕ್ ಸಂಪೂರ್ಣವಾಗಿ ಬದಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ kubectl, API ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸುವಾಗ ನೀವು ಅದನ್ನು ಅವಲಂಬಿಸಬಾರದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಪ್ರಸ್ತುತ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯನ್ನು ಓದಬೇಕು, ಅದನ್ನು ನವೀಕರಿಸಬೇಕು ಮತ್ತು ನಂತರ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು PUT ವಿನಂತಿ.

ನೀವು ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ - ನಾವು ಬದಲಾಯಿಸುತ್ತೇವೆ

ಕೆಲವೊಮ್ಮೆ ನೀವು API ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗದ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಂಪನ್ಮೂಲವನ್ನು ಅಳಿಸುವ ಮೂಲಕ ಮತ್ತು ಮರು-ರಚಿಸುವ ಮೂಲಕ ನೀವು ಅದನ್ನು ಬದಲಾಯಿಸಲು ಒತ್ತಾಯಿಸಬಹುದು. ಇದನ್ನು ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ kubectl replace --force. ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವುದರಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಕ್ಷಣವೇ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಒದಗಿಸಿದ ವಿವರಣೆಯಿಂದ ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ. API ನಲ್ಲಿ "ಫೋರ್ಸ್ ರಿಪ್ಲೇಸ್" ಹ್ಯಾಂಡ್ಲರ್ ಇಲ್ಲ, ಮತ್ತು API ಮೂಲಕ ಹಾಗೆ ಮಾಡಲು, ನೀವು ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ಮೊದಲು ನೀವು ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಅಳಿಸಬೇಕಾಗಿದೆ gracePeriodSeconds ಶೂನ್ಯಕ್ಕೆ (0) ಮತ್ತು propagationPolicy "ಹಿನ್ನೆಲೆ" ನಲ್ಲಿ ಮತ್ತು ನಂತರ ಬಯಸಿದ ವಿವರಣೆಯೊಂದಿಗೆ ಈ ಸಂಪನ್ಮೂಲವನ್ನು ಮರು-ರಚಿಸಿ.

ಎಚ್ಚರಿಕೆ: ಈ ವಿಧಾನವು ಸಂಭಾವ್ಯವಾಗಿ ಅಪಾಯಕಾರಿಯಾಗಿದೆ ಮತ್ತು ವಿವರಿಸಲಾಗದ ಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಅನ್ವಯಿಸಿ

ಮೇಲೆ ಹೇಳಿದಂತೆ, ಕುಬರ್ನೆಟ್ಸ್ ಡೆವಲಪರ್‌ಗಳು ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ apply ನಿಂದ kubectl ಕುಬರ್ನೆಟ್ಸ್ API ನಲ್ಲಿ. ತರ್ಕಶಾಸ್ತ್ರ apply ಕುಬರ್ನೆಟ್ಸ್ 1.18 ಮೂಲಕ ಲಭ್ಯವಿದೆ kubectl apply --server-side ಅಥವಾ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು API ಮೂಲಕ PATCH с content-type application/apply-patch+YAML.

ಗಮನಿಸಿ: JSON ಸಹ ಮಾನ್ಯವಾದ YAML ಆಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ನಿರ್ದಿಷ್ಟತೆಯನ್ನು JSON ಎಂದು ಕಳುಹಿಸಬಹುದು content-type ಇರುತ್ತದೆ application/apply-patch+yaml.

ಅದರ ಜೊತೆಗೆ ತರ್ಕ kubectl API ಮೂಲಕ ಎಲ್ಲರಿಗೂ ಲಭ್ಯವಾಗುತ್ತದೆ, apply ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, ನಿರ್ದಿಷ್ಟತೆಯಲ್ಲಿನ ಕ್ಷೇತ್ರಗಳಿಗೆ ಯಾರು ಜವಾಬ್ದಾರರು ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಹೀಗಾಗಿ ಅದರ ಸಂಘರ್ಷ-ಮುಕ್ತ ಸಂಪಾದನೆಗಾಗಿ ಸುರಕ್ಷಿತ ಬಹು ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ವೇಳೆ apply ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಹರಡುತ್ತದೆ, ವಿವಿಧ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಾರ್ವತ್ರಿಕ ಸುರಕ್ಷಿತ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, kubectl, Pulumi ಅಥವಾ Terraform, GitOps, ಹಾಗೆಯೇ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಯಂ-ಬರಹದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು.

ಫಲಿತಾಂಶಗಳು

ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸುವ ವಿವಿಧ ವಿಧಾನಗಳ ಈ ಕಿರು ಅವಲೋಕನವು ನಿಮಗೆ ಸಹಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇದು ಕೇವಲ ಬದಲಿ ವಿರುದ್ಧ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಎಂದು ತಿಳಿಯುವುದು ಒಳ್ಳೆಯದು; ಅನ್ವಯಿಸು, ಎಡಿಟ್, ಪ್ಯಾಚ್ ಅಥವಾ ಬದಲಿ ಬಳಸಿಕೊಂಡು ಸಂಪನ್ಮೂಲವನ್ನು ನವೀಕರಿಸಲು ಸಾಧ್ಯವಿದೆ. ಎಲ್ಲಾ ನಂತರ, ತಾತ್ವಿಕವಾಗಿ, ಪ್ರತಿಯೊಂದು ವಿಧಾನವು ತನ್ನದೇ ಆದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರದೇಶವನ್ನು ಹೊಂದಿದೆ. ಪರಮಾಣು ಬದಲಾವಣೆಗಳಿಗೆ, ಬದಲಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ; ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅನ್ವಯಿಸುವ ಮೂಲಕ ಕಾರ್ಯತಂತ್ರದ-ವಿಲೀನ ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸಬೇಕು. ಕನಿಷ್ಠ, "kubernetes apply vs replace" ಎಂದು ಹುಡುಕುವಾಗ ನೀವು Google ಅಥವಾ StackOerflow ಅನ್ನು ನಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕೆಂದು ನಾನು ನಿರೀಕ್ಷಿಸುತ್ತೇನೆ. ಕನಿಷ್ಠ ಈ ಲೇಖನವು ಪ್ರಸ್ತುತ ಉತ್ತರವನ್ನು ಬದಲಿಸುವವರೆಗೆ.

ಮೂಲ: www.habr.com