ಕಂಟೇನರ್ ಟು ಕನ್ವೇಯರ್: CRI-O ಈಗ OpenShift ಕಂಟೈನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ 4 ರಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ

ಪ್ಲಾಟ್ಫಾರ್ಮ್ Red Hat ಓಪನ್‌ಶಿಫ್ಟ್ ಕಂಟೇನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ 4 ಸೃಷ್ಟಿಯನ್ನು ಸುಗಮಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಕಂಟೈನರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಹೋಸ್ಟ್‌ಗಳು, ಕ್ಲೌಡ್ ಸೇವಾ ಪೂರೈಕೆದಾರರ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ, ವರ್ಚುವಲೈಸೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಬೇರ್-ಮೆಟಲ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಸೇರಿದಂತೆ. ನಿಜವಾದ ಕ್ಲೌಡ್-ಆಧಾರಿತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ರಚಿಸಲು, ನಾವು ಬಳಸಿದ ಎಲ್ಲಾ ಅಂಶಗಳ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಿತ್ತು ಮತ್ತು ಆದ್ದರಿಂದ ಸಂಕೀರ್ಣವಾದ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪ್ರಕ್ರಿಯೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಸ್ಪಷ್ಟ ಪರಿಹಾರವೆಂದರೆ Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux ನ ರೂಪಾಂತರ) ಮತ್ತು CRI-O ಅನ್ನು ಮಾನದಂಡವಾಗಿ ಬಳಸುವುದು, ಮತ್ತು ಇಲ್ಲಿ ಏಕೆ...

ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಕಂಟೈನರ್‌ಗಳ ಕೆಲಸವನ್ನು ವಿವರಿಸುವಾಗ ಸಾದೃಶ್ಯಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ನೌಕಾಯಾನದ ವಿಷಯವು ತುಂಬಾ ಒಳ್ಳೆಯದು, ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು CoreOS ಮತ್ತು CRI-O ಪರಿಹರಿಸುವ ವ್ಯವಹಾರ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ. ರಿಗ್ಗಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳ ಉತ್ಪಾದನೆಗೆ ಬ್ರೂನೆಲ್‌ನ ಆವಿಷ್ಕಾರಗಳು. 1803 ರಲ್ಲಿ, ಬೆಳೆಯುತ್ತಿರುವ ಬ್ರಿಟಿಷ್ ನೌಕಾಪಡೆಯ ಅಗತ್ಯಗಳಿಗಾಗಿ 100 ರಿಗ್ಗಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಮಾರ್ಕ್ ಬ್ರೂನೆಲ್ ವಹಿಸಿಕೊಂಡರು. ರಿಗ್ಗಿಂಗ್ ಬ್ಲಾಕ್ ಎನ್ನುವುದು ಒಂದು ರೀತಿಯ ರಿಗ್ಗಿಂಗ್ ಆಗಿದ್ದು, ಹಗ್ಗಗಳನ್ನು ಹಾಯಿಗಳಿಗೆ ಜೋಡಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. 19 ನೇ ಶತಮಾನದ ಆರಂಭದವರೆಗೂ, ಈ ಬ್ಲಾಕ್ಗಳನ್ನು ಕೈಯಿಂದ ಮಾಡಲಾಗುತ್ತಿತ್ತು, ಆದರೆ ಬ್ರೂನೆಲ್ ಉತ್ಪಾದನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾದರು ಮತ್ತು ಯಂತ್ರೋಪಕರಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಮಾಣಿತ ಬ್ಲಾಕ್ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ಈ ಪ್ರಕ್ರಿಯೆಯ ಆಟೊಮೇಷನ್ ಎಂದರೆ ಪರಿಣಾಮವಾಗಿ ಬರುವ ಬ್ಲಾಕ್‌ಗಳು ವಾಸ್ತವಿಕವಾಗಿ ಒಂದೇ ಆಗಿರುತ್ತವೆ, ಮುರಿದರೆ ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಉತ್ಪಾದಿಸಬಹುದು.

ಬ್ರೂನೆಲ್ ಈ ಕೆಲಸವನ್ನು 20 ವಿಭಿನ್ನ ಹಡಗು ಮಾದರಿಗಳಿಗೆ (ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿಗಳು) ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಸಮುದ್ರದ ಪ್ರವಾಹಗಳು ಮತ್ತು ಮಾರುತಗಳನ್ನು ಹೊಂದಿರುವ ಐದು ವಿಭಿನ್ನ ಗ್ರಹಗಳಿಗೆ (ಮೋಡ ಪೂರೈಕೆದಾರರು) ಮಾಡಬೇಕೇ ಎಂದು ಊಹಿಸಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಎಲ್ಲಾ ಹಡಗುಗಳು (ಓಪನ್‌ಶಿಫ್ಟ್ ಕ್ಲಸ್ಟರ್‌ಗಳು), ನ್ಯಾವಿಗೇಷನ್ ನಡೆಸುವ ಗ್ರಹಗಳನ್ನು ಲೆಕ್ಕಿಸದೆ, ಕ್ಯಾಪ್ಟನ್‌ಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ (ಗುಂಪುಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ನಿರ್ವಾಹಕರು) ಒಂದೇ ರೀತಿ ವರ್ತಿಸಬೇಕು. ಕಡಲ ಸಾದೃಶ್ಯವನ್ನು ಮುಂದುವರಿಸಲು, ಹಡಗು ಕ್ಯಾಪ್ಟನ್‌ಗಳು ತಮ್ಮ ಹಡಗುಗಳಲ್ಲಿ ಯಾವ ರೀತಿಯ ರಿಗ್ಗಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು (ಸಿಆರ್‌ಐ-ಒ) ಬಳಸುತ್ತಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ - ಅವರಿಗೆ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಈ ಬ್ಲಾಕ್‌ಗಳು ಬಲವಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿವೆ.

OpenShift 4, ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಂತೆ, ಒಂದೇ ರೀತಿಯ ವ್ಯವಹಾರ ಸವಾಲನ್ನು ಎದುರಿಸುತ್ತಿದೆ. ಕ್ಲಸ್ಟರ್ ರಚನೆಯ ಸಮಯದಲ್ಲಿ, ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಅಥವಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ರಚಿಸಬೇಕು. ಹೊಸ ನೋಡ್ ಅನ್ನು ರಚಿಸಿದಾಗ ಮತ್ತು ಪ್ರಾರಂಭಿಸಿದಾಗ, CRI-O ಸೇರಿದಂತೆ ನಿರ್ಣಾಯಕ ಹೋಸ್ಟ್ ಘಟಕಗಳನ್ನು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ಯಾವುದೇ ಇತರ ಉತ್ಪಾದನೆಯಂತೆ, "ಕಚ್ಚಾ ವಸ್ತುಗಳನ್ನು" ಆರಂಭದಲ್ಲಿ ಸರಬರಾಜು ಮಾಡಬೇಕು. ಹಡಗುಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಕಚ್ಚಾ ವಸ್ತುಗಳು ಲೋಹ ಮತ್ತು ಮರಗಳಾಗಿವೆ. ಆದಾಗ್ಯೂ, OpenShift 4 ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಹೋಸ್ಟ್ ಅನ್ನು ರಚಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು ಮತ್ತು API ಒದಗಿಸಿದ ಸರ್ವರ್‌ಗಳನ್ನು ಇನ್‌ಪುಟ್‌ನಂತೆ ಹೊಂದಿರಬೇಕು. OpenShift ನಂತರ ಸಂಪೂರ್ಣ ಜೀವನ ಚಕ್ರದಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಮಟ್ಟದ ಯಾಂತ್ರೀಕರಣವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಅಗತ್ಯವಾದ ಉತ್ಪನ್ನ ಬೆಂಬಲವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಹೀಗಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಹೂಡಿಕೆಯನ್ನು ಮರುಪಾವತಿ ಮಾಡುತ್ತದೆ.

ಎಲ್ಲಾ ಪ್ರಮುಖ ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಪೂರೈಕೆದಾರರು, ವರ್ಚುವಲೈಸೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಮತ್ತು ಬೇರ್ ಮೆಟಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಪ್ಲ್ಯಾಟ್‌ಫಾರ್ಮ್‌ನ ಸಂಪೂರ್ಣ ಜೀವನ ಚಕ್ರದಲ್ಲಿ (ಆವೃತ್ತಿ 4.X ಗಾಗಿ) ಸಿಸ್ಟಮ್ ಅನ್ನು ಅನುಕೂಲಕರವಾಗಿ ನವೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುವ ರೀತಿಯಲ್ಲಿ OpenShift 4 ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ನೋಡ್ಗಳನ್ನು ರಚಿಸಬೇಕು. ಒಂದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಕುಬರ್ನೆಟ್ಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯ ಅಗತ್ಯವಿರುವಾಗ, ಅದು CoreOS ನಲ್ಲಿ CRI-O ನ ಅನುಗುಣವಾದ ಆವೃತ್ತಿಯನ್ನು ಸಹ ಪಡೆಯುತ್ತದೆ. CRI-O ಆವೃತ್ತಿಯು ನೇರವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸಂಬಂಧಿಸಿರುವುದರಿಂದ, ಇದು ಪರೀಕ್ಷೆ, ದೋಷನಿವಾರಣೆ ಅಥವಾ ಬೆಂಬಲ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಯಾವುದೇ ಕ್ರಮಪಲ್ಲಟನೆಗಳನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈ ವಿಧಾನವು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಮತ್ತು Red Hat ಗೆ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಕುರಿತು ಯೋಚಿಸುವ ಮೂಲಭೂತವಾಗಿ ಹೊಸ ಮಾರ್ಗವಾಗಿದೆ ಮತ್ತು ಕೆಲವು ಉಪಯುಕ್ತ ಮತ್ತು ಬಲವಾದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಯೋಜಿಸಲು ಅಡಿಪಾಯವನ್ನು ಹಾಕುತ್ತದೆ. CRI-O (ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಇಂಟರ್ಫೇಸ್ - ಓಪನ್ ಕಂಟೈನರ್ ಇನಿಶಿಯೇಟಿವ್, ಸಂಕ್ಷಿಪ್ತ CRI-OCI) ಓಪನ್ ಶಿಫ್ಟ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅಗತ್ಯವಾದ ನೋಡ್ಗಳ ಸಮೂಹ ರಚನೆಗೆ ಅತ್ಯಂತ ಯಶಸ್ವಿ ಆಯ್ಕೆಯಾಗಿದೆ. CRI-O ಹಿಂದೆ ಬಳಸಿದ ಡಾಕರ್ ಎಂಜಿನ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಓಪನ್‌ಶಿಫ್ಟ್ ಬಳಕೆದಾರರನ್ನು ನೀಡುತ್ತದೆ ಆರ್ಥಿಕ, ಸ್ಥಿರ, ಸರಳ ಮತ್ತು ನೀರಸ - ಹೌದು, ನೀವು ಸರಿಯಾಗಿ ಕೇಳಿದ್ದೀರಿ - ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿಶೇಷವಾಗಿ ರಚಿಸಲಾದ ನೀರಸ ಕಂಟೇನರ್ ಎಂಜಿನ್.

ತೆರೆದ ಪಾತ್ರೆಗಳ ಜಗತ್ತು

ಪ್ರಪಂಚವು ದೀರ್ಘಕಾಲದವರೆಗೆ ತೆರೆದ ಪಾತ್ರೆಗಳತ್ತ ಸಾಗುತ್ತಿದೆ. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿರಲಿ ಅಥವಾ ಕೆಳಮಟ್ಟದಲ್ಲಿರಲಿ, ಕಂಟೇನರ್ ಮಾನದಂಡಗಳ ಅಭಿವೃದ್ಧಿ ಪ್ರತಿ ಹಂತದಲ್ಲೂ ನಾವೀನ್ಯತೆಯ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಓಪನ್ ಕಂಟೈನರ್ ಇನಿಶಿಯೇಟಿವ್ ರಚನೆಯೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಯಿತು ಜೂನ್ 2015 ರಲ್ಲಿ. ಕೆಲಸದ ಈ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ, ಕಂಟೇನರ್ ವಿಶೇಷಣಗಳು ರೂಪುಗೊಂಡವು ಚಿತ್ರ и ರನ್ಟೈಮ್ ಪರಿಸರ. ಉಪಕರಣಗಳು ಒಂದೇ ಮಾನದಂಡವನ್ನು ಬಳಸಬಹುದೆಂದು ಇದು ಖಚಿತಪಡಿಸಿತು ಕಂಟೇನರ್ ಚಿತ್ರಗಳು ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಏಕೀಕೃತ ಸ್ವರೂಪ. ವಿಶೇಷಣಗಳನ್ನು ನಂತರ ಸೇರಿಸಲಾಯಿತು ವಿತರಣೆ, ಬಳಕೆದಾರರಿಗೆ ಸುಲಭವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ ಕಂಟೇನರ್ ಚಿತ್ರಗಳು.

ಕುಬರ್ನೆಟ್ಸ್ ಸಮುದಾಯವು ನಂತರ ಪ್ಲಗ್ ಮಾಡಬಹುದಾದ ಇಂಟರ್ಫೇಸ್‌ಗಾಗಿ ಒಂದೇ ಮಾನದಂಡವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿತು ಕಂಟೈನರ್ ರನ್ಟೈಮ್ ಇಂಟರ್ಫೇಸ್ (CRI). ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಕುಬರ್ನೆಟ್ಸ್ ಬಳಕೆದಾರರು ಡಾಕರ್ ಜೊತೆಗೆ ಕಂಟೇನರ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿವಿಧ ಎಂಜಿನ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಯಿತು.

Red Hat ಮತ್ತು Google ನಲ್ಲಿನ ಇಂಜಿನಿಯರ್‌ಗಳು CRI ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ Kubelet ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಕಂಟೈನರ್ ಎಂಜಿನ್‌ನ ಮಾರುಕಟ್ಟೆಯ ಅಗತ್ಯವನ್ನು ಕಂಡರು ಮತ್ತು ಮೇಲೆ ತಿಳಿಸಲಾದ OCI ವಿಶೇಷಣಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಕಂಟೈನರ್‌ಗಳನ್ನು ಪರಿಚಯಿಸಿದರು. ಆದ್ದರಿಂದ OCID ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಆದರೆ ಕ್ಷಮಿಸಿ, ಈ ವಸ್ತುವನ್ನು CRI-O ಗೆ ಸಮರ್ಪಿಸಲಾಗುವುದು ಎಂದು ನಾವು ಹೇಳಲಿಲ್ಲವೇ? ವಾಸ್ತವವಾಗಿ ಇದು, ಕೇವಲ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಆವೃತ್ತಿ 1.0 ಯೋಜನೆಯನ್ನು CRI-O ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡಲಾಯಿತು.

ಅಂಜೂರ. 1

CRI-O ಮತ್ತು CoreOS ನೊಂದಿಗೆ ನಾವೀನ್ಯತೆ

ಓಪನ್‌ಶಿಫ್ಟ್ 4 ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಪ್ರಾರಂಭದೊಂದಿಗೆ, ಅದನ್ನು ಬದಲಾಯಿಸಲಾಯಿತು ಕಂಟೇನರ್ ಎಂಜಿನ್, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಬಳಸಲಾಗಿದೆ ಮತ್ತು ಡಾಕರ್ ಅನ್ನು CRI-O ನಿಂದ ಬದಲಾಯಿಸಲಾಯಿತು, ಇದು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸಮಾನಾಂತರವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಕಂಟೇನರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿ, ಸ್ಥಿರ, ಸರಳ ಮತ್ತು ನೀರಸ ವಾತಾವರಣವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಕ್ಲಸ್ಟರ್ ಬೆಂಬಲ ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಎಂಜಿನ್ ಮತ್ತು ಹೋಸ್ಟ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್, ಹಾಗೆಯೇ ಅವುಗಳ ನಿರ್ವಹಣೆ, ಓಪನ್‌ಶಿಫ್ಟ್ 4 ರೊಳಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗುತ್ತದೆ.

ನಿರೀಕ್ಷಿಸಿ, ಇದು ಹೇಗೆ?

ಅದು ಸರಿ, ಓಪನ್‌ಶಿಫ್ಟ್ 4 ರ ಆಗಮನದೊಂದಿಗೆ, ಇನ್ನು ಮುಂದೆ ಪ್ರತ್ಯೇಕ ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಕಂಟೇನರ್ ಎಂಜಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ಸಂಗ್ರಹಣೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಹುಡುಕಾಟ ಸರ್ವರ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. OpenShift 4 ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ಸಂಪೂರ್ಣವಾಗಿ ಮರುವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಆಪರೇಟರ್ ಫ್ರೇಮ್ವರ್ಕ್ ಅಂತಿಮ-ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ವಿಷಯದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ, ಚಿತ್ರಗಳನ್ನು ನಿಯೋಜಿಸುವುದು, ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಅಥವಾ ನವೀಕರಣಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದು ಮುಂತಾದ ಮೂಲಭೂತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ಮಟ್ಟದ ಕಾರ್ಯಾಚರಣೆಗಳ ಪರಿಭಾಷೆಯಲ್ಲಿಯೂ ಸಹ.

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

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಆಪರೇಟರ್‌ಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ, ಓಪನ್‌ಶಿಫ್ಟ್ 4 ಈ ಹೊಸ ಮಾದರಿಯನ್ನು (ಸೆಟ್ ಮತ್ತು ನಿಜವಾದ ಸ್ಥಿತಿಯ ಪರಿಕಲ್ಪನೆಯನ್ನು ಬಳಸಿಕೊಂಡು) RHEL CoreOS ಮತ್ತು CRI-O ನಿರ್ವಹಣೆಗೆ ತರುತ್ತದೆ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮತ್ತು ಕಂಟೇನರ್ ಎಂಜಿನ್ ಆವೃತ್ತಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯಗಳು ಕರೆಯಲ್ಪಡುವದನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತವೆ ಯಂತ್ರ ಸಂರಚನಾ ಆಪರೇಟರ್ (MCO). MCO ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರ ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಮೂಲಭೂತವಾಗಿ ಅನುಸ್ಥಾಪನೆಯ ಕೊನೆಯ ಹಂತಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ, ಜೊತೆಗೆ ನಂತರದ ಅನುಸ್ಥಾಪನೆಯ ನಂತರದ ಕಾರ್ಯಾಚರಣೆಗಳು (ದಿನ ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳು). ಇದೆಲ್ಲವೂ ಓಪನ್‌ಶಿಫ್ಟ್ 4 ಅನ್ನು ನಿಜವಾದ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಾಡುತ್ತದೆ. ನಾವು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಇದನ್ನು ಪ್ರವೇಶಿಸುತ್ತೇವೆ.

ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್ಗಳು

ಟೆಕ್ ಪೂರ್ವವೀಕ್ಷಣೆ ಸ್ಥಿತಿಯಲ್ಲಿ ಆವೃತ್ತಿ 3.7 ರಿಂದ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಲಭ್ಯವಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿ (ಪ್ರಸ್ತುತ ಬೆಂಬಲಿತವಾಗಿದೆ) ಆವೃತ್ತಿ 3.9 ರಿಂದ ಓಪನ್‌ಶಿಫ್ಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ CRI-O ಎಂಜಿನ್ ಅನ್ನು ಬಳಸುವ ಅವಕಾಶವನ್ನು ಬಳಕೆದಾರರು ಹೊಂದಿದ್ದಾರೆ. ಇದರ ಜೊತೆಗೆ, Red Hat ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿ ಬಳಸುತ್ತದೆ CRI-O ಉತ್ಪಾದನಾ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಚಲಾಯಿಸಲು ಆವೃತ್ತಿ 3.10 ರಿಂದ OpenShift ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ. ಇದೆಲ್ಲವೂ CRI-O ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ತಂಡಕ್ಕೆ ದೊಡ್ಡ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಸಾಮೂಹಿಕ ಉಡಾವಣೆ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ವ್ಯಾಪಕ ಅನುಭವವನ್ನು ಪಡೆಯಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಕುಬರ್ನೆಟ್ಸ್ CRI-O ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಮೂಲಭೂತ ತಿಳುವಳಿಕೆಯನ್ನು ಪಡೆಯಲು, ಕೆಳಗಿನ ವಿವರಣೆಯನ್ನು ನೋಡೋಣ, ಇದು ವಾಸ್ತುಶಿಲ್ಪವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 2. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ

ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಮತ್ತು ಓಪನ್‌ಶಿಫ್ಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವಾಗ ಸಂಪೂರ್ಣ ಉನ್ನತ ಮಟ್ಟವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಮೂಲಕ ಹೊಸ ಕಂಟೇನರ್ ಹೋಸ್ಟ್‌ಗಳ ರಚನೆಯನ್ನು CRI-O ಸರಳಗೊಳಿಸುತ್ತದೆ. ಸಂಪೂರ್ಣ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಪರಿಷ್ಕರಣೆಯು ವಹಿವಾಟಿನ ನವೀಕರಣಗಳು/ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಕಂಟೇನರ್ ಟೈಲ್ ಕೋರ್, ಕಂಟೈನರ್ ಎಂಜಿನ್, ನೋಡ್‌ಗಳು (ಕುಬೆಲೆಟ್ಸ್) ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಮಾಸ್ಟರ್ ನೋಡ್ ನಡುವಿನ ಅವಲಂಬನೆಗಳಲ್ಲಿ ಡೆಡ್‌ಲಾಕ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ನಿಯಂತ್ರಣ ಮತ್ತು ಆವೃತ್ತಿಯೊಂದಿಗೆ ಎಲ್ಲಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಘಟಕಗಳನ್ನು ಕೇಂದ್ರೀಯವಾಗಿ ನಿರ್ವಹಿಸುವ ಮೂಲಕ, ರಾಜ್ಯ A ನಿಂದ ರಾಜ್ಯ B ಗೆ ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾದ ಮಾರ್ಗವಿದೆ. ಇದು ನವೀಕರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ವರದಿಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಗಳ ನವೀಕರಣಗಳು ಮತ್ತು ಸ್ಥಾಪನೆಗಳ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. .

ಬದಲಿ ಅಂಶಗಳ ಶಕ್ತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುವುದು

ಮೊದಲೇ ಹೇಳಿದಂತೆ, OpenShift 4 ನಲ್ಲಿ ಕಂಟೇನರ್ ಹೋಸ್ಟ್ ಮತ್ತು ಕಂಟೇನರ್ ಎಂಜಿನ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಯಂತ್ರ ಕಾನ್ಫಿಗ್ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸುವುದು ಕುಬರ್ನೆಟ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಹಿಂದೆ ಸಾಧ್ಯವಾಗದ ಹೊಸ ಮಟ್ಟದ ಸ್ವಯಂಚಾಲಿತತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು, ನೀವು crio.conf ಫೈಲ್‌ಗೆ ಹೇಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ. ಪರಿಭಾಷೆಯಿಂದ ಗೊಂದಲಕ್ಕೀಡಾಗುವುದನ್ನು ತಪ್ಪಿಸಲು, ಫಲಿತಾಂಶಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸಿ.

ಮೊದಲಿಗೆ, ಕಂಟೈನರ್ ರನ್ಟೈಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಎಂದು ಕರೆಯಲ್ಪಡುವದನ್ನು ರಚಿಸೋಣ - ಕಂಟೈನರ್ ರನ್ಟೈಮ್ ಕಾನ್ಫಿಗರೇಶನ್. CRI-O ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲ ಎಂದು ಯೋಚಿಸಿ. ವಾಸ್ತವದಲ್ಲಿ, ಇದು MachineConfig ಎಂಬ ಯಾವುದೋ ಒಂದು ವಿಶೇಷ ಆವೃತ್ತಿಯಾಗಿದೆ, ಇದು OpenShift ಕ್ಲಸ್ಟರ್‌ನ ಭಾಗವಾಗಿ RHEL CoreOS ಯಂತ್ರಕ್ಕೆ ನಿಯೋಜಿಸಲಾದ ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿದೆ.

CRI-O ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರಿಗೆ ಸುಲಭವಾಗಿಸಲು ContainerRuntimeConfig ಎಂದು ಕರೆಯಲ್ಪಡುವ ಈ ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಲಾಗಿದೆ. ಈ ಉಪಕರಣವು MachineConfigPool ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿ ಕೆಲವು ನೋಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸಬಹುದಾದಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿದೆ. ಅದೇ ಉದ್ದೇಶವನ್ನು ಪೂರೈಸುವ ಯಂತ್ರಗಳ ಗುಂಪು ಎಂದು ಯೋಚಿಸಿ.

/etc/crio/crio.conf ಫೈಲ್‌ನಲ್ಲಿ ನಾವು ಬದಲಾಯಿಸಲಿರುವ ಕೊನೆಯ ಎರಡು ಸಾಲುಗಳನ್ನು ಗಮನಿಸಿ. ಈ ಎರಡು ಸಾಲುಗಳು crio.conf ಫೈಲ್‌ನಲ್ಲಿರುವ ಸಾಲುಗಳಿಗೆ ಹೋಲುತ್ತವೆ, ಅವುಗಳು:

vi ContainerRuntimeConfig.yaml

ತೀರ್ಮಾನ:

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

ಈಗ ನಾವು ಈ ಫೈಲ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ತಳ್ಳೋಣ ಮತ್ತು ಅದನ್ನು ನಿಜವಾಗಿ ರಚಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ. ಕಾರ್ಯಾಚರಣೆಯು ಯಾವುದೇ ಇತರ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳಂತೆಯೇ ಇರುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

ತೀರ್ಮಾನ:

NAME              AGE
set-log-and-pid   22h

ಒಮ್ಮೆ ನಾವು ContainerRuntimeConfig ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ನಾವು ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನಿರ್ದಿಷ್ಟ ಗುಂಪಿನ ಯಂತ್ರಗಳಿಗೆ ಅನ್ವಯಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಸಂಕೇತಿಸಲು MachineConfigPools ಒಂದನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಮಾಸ್ಟರ್ ನೋಡ್‌ಗಳಿಗಾಗಿ MachineConfigPool ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ:

oc edit MachineConfigPool/master

ತೀರ್ಮಾನ (ಸ್ಪಷ್ಟತೆಗಾಗಿ, ಮುಖ್ಯ ಸಾರವು ಉಳಿದಿದೆ):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

ಈ ಹಂತದಲ್ಲಿ, MCO ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಹೊಸ crio.conf ಫೈಲ್ ಅನ್ನು ರಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪೂರ್ಣವಾಗಿ ಮುಗಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ API ಬಳಸಿ ವೀಕ್ಷಿಸಬಹುದು. ನೆನಪಿಡಿ, ContainerRuntimeConfig ಕೇವಲ MachineConfig ನ ವಿಶೇಷ ಆವೃತ್ತಿಯಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು MachineConfigs ನಲ್ಲಿ ಸಂಬಂಧಿತ ಸಾಲುಗಳನ್ನು ನೋಡುವ ಮೂಲಕ ಫಲಿತಾಂಶವನ್ನು ನೋಡಬಹುದು:

oc get MachineConfigs | grep rendered

ತೀರ್ಮಾನ:

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

ಮಾಸ್ಟರ್ ನೋಡ್‌ಗಳಿಗಾಗಿ ಪರಿಣಾಮವಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಮೂಲ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗಿಂತ ಹೊಸ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಅದನ್ನು ವೀಕ್ಷಿಸಲು, ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ. ಹಾದುಹೋಗುವಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಇತಿಹಾಸದಲ್ಲಿ ಇದು ಬಹುಶಃ ಅತ್ಯುತ್ತಮ ಒನ್-ಲೈನರ್ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ:

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

ತೀರ್ಮಾನ:

pids_limit = 2048

ಈಗ ಎಲ್ಲಾ ಮಾಸ್ಟರ್ ನೋಡ್‌ಗಳಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅನ್ವಯಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳೋಣ. ಮೊದಲು ನಾವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೋಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ:

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

ಈಗ ಸ್ಥಾಪಿಸಲಾದ ಫೈಲ್ ಅನ್ನು ನೋಡೋಣ. ContainerRuntimeConfig ಸಂಪನ್ಮೂಲದಲ್ಲಿ ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ pid ಮತ್ತು ಡೀಬಗ್ ನಿರ್ದೇಶನಗಳಿಗಾಗಿ ಫೈಲ್ ಅನ್ನು ಹೊಸ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ನವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ. ಸೊಬಗು ಸ್ವತಃ:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

ತೀರ್ಮಾನ:

...
pids_limit = 2048
...
log_level = "debug"
...

ಕ್ಲಸ್ಟರ್‌ಗೆ ಈ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು SSH ಅನ್ನು ಚಾಲನೆ ಮಾಡದೆಯೇ ಮಾಡಲಾಗಿದೆ. ಕುಬೆರೆಂಟೆಸ್ ಮಾಸ್ಟರ್ ನೋಡ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಮೂಲಕ ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ಅಂದರೆ, ಈ ಹೊಸ ನಿಯತಾಂಕಗಳನ್ನು ಮಾಸ್ಟರ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ವರ್ಕರ್ ನೋಡ್‌ಗಳು ಬದಲಾಗಲಿಲ್ಲ, ಇದು ಕಂಟೇನರ್ ಹೋಸ್ಟ್‌ಗಳು ಮತ್ತು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಅಂಶಗಳೊಂದಿಗೆ ಕಂಟೇನರ್ ಎಂಜಿನ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮತ್ತು ವಾಸ್ತವಿಕ ಸ್ಥಿತಿಗಳನ್ನು ಬಳಸುವ ಕುಬರ್ನೆಟ್ಸ್ ವಿಧಾನದ ಪ್ರಯೋಜನಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ಮೇಲಿನ ಉದಾಹರಣೆಯು ಮೂರು ಪ್ರೊಡಕ್ಷನ್ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಣ್ಣ ಓಪನ್‌ಶಿಫ್ಟ್ ಕಂಟೈನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ 4 ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ ಅಥವಾ 3000 ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಬೃಹತ್ ಉತ್ಪಾದನಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲಸದ ಪ್ರಮಾಣವು ಒಂದೇ ಆಗಿರುತ್ತದೆ - ಮತ್ತು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ - ContainerRuntimeConfig ಫೈಲ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು MachineConfigPool ನಲ್ಲಿ ಒಂದು ಲೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸಿ. ಮತ್ತು ನೀವು ಇದನ್ನು OpenShift ಕಂಟೈನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ 4.X ನ ಯಾವುದೇ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಅದರ ಜೀವನಚಕ್ರದ ಉದ್ದಕ್ಕೂ ಕುಬರ್ನೆಟ್ಸ್ ಚಾಲನೆಯಲ್ಲಿ ಮಾಡಬಹುದು.

ಸಾಮಾನ್ಯವಾಗಿ ತಂತ್ರಜ್ಞಾನ ಕಂಪನಿಗಳು ಎಷ್ಟು ಬೇಗನೆ ವಿಕಸನಗೊಳ್ಳುತ್ತವೆ ಎಂದರೆ ನಾವು ಆಧಾರವಾಗಿರುವ ಘಟಕಗಳಿಗೆ ಕೆಲವು ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಏಕೆ ಆರಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಕಂಟೈನರ್ ಎಂಜಿನ್‌ಗಳು ಐತಿಹಾಸಿಕವಾಗಿ ಬಳಕೆದಾರರು ನೇರವಾಗಿ ಸಂವಹಿಸುವ ಅಂಶವಾಗಿದೆ. ಕಂಟೇನರ್ ಎಂಜಿನ್‌ಗಳ ಆಗಮನದಿಂದ ಕಂಟೇನರ್‌ಗಳ ಜನಪ್ರಿಯತೆಯು ಸ್ವಾಭಾವಿಕವಾಗಿ ಪ್ರಾರಂಭವಾದಾಗಿನಿಂದ, ಬಳಕೆದಾರರು ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಆಸಕ್ತಿಯನ್ನು ತೋರಿಸುತ್ತಾರೆ. Red Hat CRI-O ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಇದು ಮತ್ತೊಂದು ಕಾರಣವಾಗಿದೆ. ಕಂಟೈನರ್‌ಗಳು ಈಗ ವಾದ್ಯವೃಂದದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿವೆ ಮತ್ತು OpenShift 4 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ CRI-O ಅತ್ಯುತ್ತಮ ಅನುಭವವನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.

ಮೂಲ: www.habr.com