ಕಸ್ಟಮೈಜ್ ಮಾಡಲು ಸಂಕ್ಷಿಪ್ತ ಪರಿಚಯ

ಸೂಚನೆ. ಅನುವಾದ.: ಲೇಖನವನ್ನು ಸ್ಕಾಟ್ ಲೋವ್ ಅವರು ಬರೆದಿದ್ದಾರೆ, ಅವರು IT ಯಲ್ಲಿ ವ್ಯಾಪಕ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅವರು ಏಳು ಮುದ್ರಿತ ಪುಸ್ತಕಗಳ ಲೇಖಕ/ಸಹ-ಲೇಖಕರಾಗಿದ್ದಾರೆ (ಮುಖ್ಯವಾಗಿ VMware vSphere ನಲ್ಲಿ). ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ಅದರ VMware ಅಂಗಸಂಸ್ಥೆಯಾದ Heptio (2016 ರಲ್ಲಿ ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಿತು) ಗಾಗಿ ಅವರು ಈಗ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಪಠ್ಯವು ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಸಂರಚನಾ ನಿರ್ವಹಣೆಗೆ ಸಂಕ್ಷಿಪ್ತ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ ಪರಿಚಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಕಸ್ಟಮೈಸ್ ಮಾಡಿ, ಇದು ಇತ್ತೀಚೆಗೆ K8s ನ ಭಾಗವಾಯಿತು.

ಕಸ್ಟಮೈಜ್ ಎನ್ನುವುದು ಬಳಕೆದಾರರಿಗೆ "ವಿವಿಧ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಸರಳವಾದ, ಟೆಂಪ್ಲೇಟ್-ಮುಕ್ತ YAML ಫೈಲ್‌ಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ಅನುಮತಿಸುವ ಒಂದು ಸಾಧನವಾಗಿದೆ, ಮೂಲ YAML ಅನ್ನು ಹಾಗೇ ಮತ್ತು ಬಳಸಬಹುದಾಗಿದೆ" (ವಿವರಣೆಯನ್ನು ನೇರವಾಗಿ ಎರವಲು ಪಡೆಯಲಾಗಿದೆ GitHub ನಲ್ಲಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಿ) ಕಸ್ಟಮೈಜ್ ಅನ್ನು ನೇರವಾಗಿ ಚಲಾಯಿಸಬಹುದು ಅಥವಾ ಕುಬರ್ನೆಟ್ಸ್ 1.14 ರಂತೆ ಬಳಸಬಹುದು kubectl -k ಅದರ ಕಾರ್ಯವನ್ನು ಪ್ರವೇಶಿಸಲು (ಕುಬರ್ನೆಟ್ಸ್ 1.15 ರಂತೆ, ಪ್ರತ್ಯೇಕ ಬೈನರಿಯು kubectl ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಸಾಮರ್ಥ್ಯಗಳಿಗಿಂತ ಹೊಸದು). (ಸೂಚನೆ. ಅನುವಾದ.: ಮತ್ತು ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಕುಬರ್ನೆಟೀಸ್ 1.16 ಕಸ್ಟಮೈಸ್ ಮಾಡಿ ಬೆಂಬಲಿಸುತ್ತದೆ kubeadm ಉಪಯುಕ್ತತೆಯಲ್ಲಿಯೂ ಸಹ.) ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ನಾನು ಕಸ್ಟಮೈಜ್‌ನ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಓದುಗರಿಗೆ ಪರಿಚಯಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಅದರ ಸರಳ ರೂಪ/ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, kustomize ಎನ್ನುವುದು ಕೇವಲ ಸಂಪನ್ಮೂಲಗಳ ಸಂಗ್ರಹವಾಗಿದೆ (ಕುಬರ್ನೆಟ್ಸ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ YAML ಫೈಲ್‌ಗಳು: ನಿಯೋಜನೆಗಳು, ಸೇವೆಗಳು, ಇತ್ಯಾದಿ.) ಜೊತೆಗೆ ಆ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಮಾಡಬೇಕಾದ ಬದಲಾವಣೆಗಳಿಗೆ ಸೂಚನೆಗಳ ಪಟ್ಟಿ. ಮಾಡು ಅದರಲ್ಲಿರುವ ಸೂಚನಾ ಸೆಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ Makefile, ಮತ್ತು ಡಾಕರ್ ಸೂಚನೆಗಳನ್ನು ಆಧರಿಸಿ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ Dockerfile, ಬಳಕೆಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಿ kustomization.yaml ಸಂಪನ್ಮೂಲಗಳ ಗುಂಪಿಗೆ ಬಳಕೆದಾರರು ಯಾವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಬಯಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಸೂಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು.

ಒಂದು ಉದಾಹರಣೆ ಫೈಲ್ ಇಲ್ಲಿದೆ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ಫೈಲ್‌ನಲ್ಲಿ ಸಂಭವನೀಯ ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನಾನು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ. kustomization.yaml (ಇದರ ಬಗ್ಗೆ ಚೆನ್ನಾಗಿ ಬರೆಯಲಾಗಿದೆ ಇಲ್ಲಿ), ಆದರೆ ನಾನು ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಯ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆಯನ್ನು ನೀಡುತ್ತೇನೆ:

• ಕ್ಷೇತ್ರ resources ಏನು (ಯಾವ ಸಂಪನ್ಮೂಲಗಳು) ಕಸ್ಟಮೈಜ್ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಫೈಲ್‌ಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹುಡುಕುತ್ತದೆ deployment.yaml и service.yaml ನಿಮ್ಮ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ (ಅಗತ್ಯವಿದ್ದಲ್ಲಿ ನೀವು ಪೂರ್ಣ ಅಥವಾ ಸಂಬಂಧಿತ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು).
• ಕ್ಷೇತ್ರ namePrefix ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಸೇರಿಸಲು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ಸೂಚನೆ ನೀಡುತ್ತದೆ (ಈ ಸಂದರ್ಭದಲ್ಲಿ - dev-) ಗುಣಲಕ್ಷಣ name ಕ್ಷೇತ್ರದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳು resources. ಹೀಗಾಗಿ, ನಿಯೋಜನೆ ಹೊಂದಿದ್ದರೆ name ಅರ್ಥದೊಂದಿಗೆ nginx-deployment, ಕಸ್ಟಮೈಸ್ ಮಾಡುತ್ತದೆ dev-nginx-deployment.
• ಕ್ಷೇತ್ರ namespace ಕೊಟ್ಟಿರುವ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸೇರಿಸಲು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ಸೂಚನೆ ನೀಡುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಯೋಜನೆ ಮತ್ತು ಸೇವೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಸೇರುತ್ತದೆ development.
• ಅಂತಿಮವಾಗಿ, ಕ್ಷೇತ್ರ commonLabels ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸೇರಿಸಲಾಗುವ ಲೇಬಲ್‌ಗಳ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿದೆ. ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, kustomize ಹೆಸರಿನೊಂದಿಗೆ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಲೇಬಲ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ environment ಮತ್ತು ಅರ್ಥ development.

ಬಳಕೆದಾರರು ಮಾಡಿದರೆ kustomize build . ಫೈಲ್ನೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ kustomization.yaml ಮತ್ತು ಅಗತ್ಯ ಸಂಪನ್ಮೂಲಗಳು (ಅಂದರೆ ಫೈಲ್‌ಗಳು deployment.yaml и service.yaml), ನಂತರ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಅದು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಪಠ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ kustomization.yaml.

ಸೂಚನೆ. ಅನುವಾದ.: ಕಸ್ಟಮೈಜ್‌ನ "ಸರಳ" ಬಳಕೆಯ ಕುರಿತು ಯೋಜನೆಯ ದಾಖಲಾತಿಯಿಂದ ವಿವರಣೆ

ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾದರೆ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸಬಹುದು:

kustomize build . > custom-config.yaml

ಔಟ್‌ಪುಟ್ ಡೇಟಾವು ನಿರ್ಣಾಯಕವಾಗಿದೆ (ಅದೇ ಇನ್‌ಪುಟ್ ಡೇಟಾವು ಅದೇ ಔಟ್‌ಪುಟ್ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ), ಆದ್ದರಿಂದ ನೀವು ಫಲಿತಾಂಶವನ್ನು ಫೈಲ್‌ಗೆ ಉಳಿಸಬೇಕಾಗಿಲ್ಲ. ಬದಲಾಗಿ, ಅದನ್ನು ನೇರವಾಗಿ ಮತ್ತೊಂದು ಆಜ್ಞೆಗೆ ರವಾನಿಸಬಹುದು:

kustomize build . | kubectl apply -f -

ಕಸ್ಟಮೈಸ್ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸಹ ಪ್ರವೇಶಿಸಬಹುದು kubectl -k (ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿ 1.14 ರಿಂದ). ಆದಾಗ್ಯೂ, ಸ್ವತಂತ್ರವಾದ kustomize ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಇಂಟಿಗ್ರೇಟೆಡ್ kubectl ಪ್ಯಾಕೇಜ್‌ಗಿಂತ ವೇಗವಾಗಿ ನವೀಕರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ (ಕನಿಷ್ಠ ಇದು ಕುಬರ್ನೆಟ್ಸ್ 1.15 ಬಿಡುಗಡೆಯ ಸಂದರ್ಭದಲ್ಲಿ).

ಓದುಗರು ಕೇಳಬಹುದು: "ನೀವು ಫೈಲ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಸಂಪಾದಿಸಬಹುದಾದರೆ ಈ ಸಂಕೀರ್ಣತೆ ಏಕೆ?" ದೊಡ್ಡ ಪ್ರಶ್ನೆ. ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ವಾಸ್ತವವಾಗಿ ಮಾಡಬಹುದು ಫೈಲ್ಗಳನ್ನು ಮಾರ್ಪಡಿಸಿ deployment.yaml и service.yaml ನೇರವಾಗಿ, ಆದರೆ ಅವರು ಬೇರೊಬ್ಬರ ಯೋಜನೆಯ ಫೋರ್ಕ್ ಆಗಿದ್ದರೆ ಏನು? ಫೈಲ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಬದಲಾಯಿಸುವುದರಿಂದ ಮೂಲ/ಮೂಲಕ್ಕೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ ಫೋರ್ಕ್ ಅನ್ನು ಮರುಬೇಸ್ ಮಾಡಲು ಕಷ್ಟವಾಗುತ್ತದೆ (ಅಸಾಧ್ಯವಲ್ಲದಿದ್ದರೆ). kustomize ಅನ್ನು ಬಳಸುವುದರಿಂದ ಫೈಲ್‌ನಲ್ಲಿ ಈ ಬದಲಾವಣೆಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ kustomization.yaml, ಮೂಲ ಫೈಲ್‌ಗಳನ್ನು ಹಾಗೆಯೇ ಬಿಡುವುದು ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಮೂಲ ಫೈಲ್‌ಗಳನ್ನು ಮರುಬೇಸ್ ಮಾಡುವುದು ಸುಲಭವಾಗುತ್ತದೆ.

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

ಮೇಲ್ಪದರಗಳು ಮತ್ತು ಆಧಾರವಾಗಿರುವ ಸಂಪನ್ಮೂಲಗಳ ಕಲ್ಪನೆಯನ್ನು ವಿವರಿಸಲು (ಮೂಲ ಸಂಪನ್ಮೂಲಗಳು), ಡೈರೆಕ್ಟರಿಗಳು ಈ ಕೆಳಗಿನ ರಚನೆಯನ್ನು ಹೊಂದಿವೆ ಎಂದು ಭಾವಿಸೋಣ:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

ಕಡತದಲ್ಲಿ base/kustomization.yaml ಕ್ಷೇತ್ರವನ್ನು ಬಳಸುವ ಬಳಕೆದಾರರು resources ಕಸ್ಟಮೈಜ್ ಒಳಗೊಂಡಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಳವಾಗಿ ಘೋಷಿಸಿ.

ಪ್ರತಿಯೊಂದು ಫೈಲ್‌ಗಳಲ್ಲಿ overlays/{dev,staging,prod}/kustomization.yaml ಬಳಕೆದಾರರು ಕ್ಷೇತ್ರದಲ್ಲಿ ಬೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತಾರೆ resources, ತದನಂತರ ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಗಳನ್ನು ಸೂಚಿಸಿ ನೀಡಿದ ಪರಿಸರ. ಉದಾಹರಣೆಗೆ, ಫೈಲ್ overlays/dev/kustomization.yaml ಹಿಂದೆ ನೀಡಿದ ಉದಾಹರಣೆಯಂತೆ ಕಾಣಿಸಬಹುದು:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕಡತ overlays/prod/kustomization.yaml ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿರಬಹುದು:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

ಬಳಕೆದಾರರು ಓಡಿದಾಗ kustomize build . ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿ overlays/dev, kustomize ಅಭಿವೃದ್ಧಿ ಆಯ್ಕೆಯನ್ನು ರಚಿಸುತ್ತದೆ. ನೀವು ಓಡಿದರೆ kustomize build . ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿ overlays/prod - ನೀವು ಉತ್ಪಾದನಾ ಆಯ್ಕೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಮತ್ತು ಇದೆಲ್ಲವೂ - ಮೂಲಕ್ಕೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡದೆಯೇ (ಆಧಾರ) ಫೈಲ್‌ಗಳು, ಎಲ್ಲಾ ಘೋಷಣಾತ್ಮಕ ಮತ್ತು ನಿರ್ಣಾಯಕ ರೀತಿಯಲ್ಲಿ. ನೀವು ಬೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಓವರ್‌ಲೇ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ನೇರವಾಗಿ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣಕ್ಕೆ ಒಪ್ಪಿಸಬಹುದು, ಈ ಫೈಲ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ನೀವು ಬಯಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಪುನರುತ್ಪಾದಿಸಬಹುದು ಎಂದು ತಿಳಿದುಕೊಳ್ಳಿ.

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

ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದು ಹೆಚ್ಚು ಈ ಲೇಖನದಲ್ಲಿ ಒಳಗೊಂಡಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು. ಆದಾಗ್ಯೂ, ಇದು ಉತ್ತಮ ಪರಿಚಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಹೆಚ್ಚುವರಿ ಸಂಪನ್ಮೂಲಗಳು

ಕಸ್ಟಮೈಜ್ ಕುರಿತು ಅನೇಕ ಉತ್ತಮ ಲೇಖನಗಳು ಮತ್ತು ಪ್ರಕಟಣೆಗಳಿವೆ. ನಾನು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವೆಂದು ಕಂಡುಕೊಂಡ ಕೆಲವು ಇಲ್ಲಿವೆ:

• ಕಸ್ಟೊಮೈಜ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವಿವಿಧ ಪರಿಸರಗಳ ಉತ್ಪನ್ನ/ಪರೀಕ್ಷೆಗಾಗಿ ಮೂಲ YAML ಸಂರಚನೆಯನ್ನು ಬದಲಾಯಿಸಿ;
• ಕಸ್ಟಮೈಜ್ - ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಮಾಡಲು ಸರಿಯಾದ ಮಾರ್ಗ;
• ಕಸ್ಟಮೈಸ್ ಬಳಸಿ ಕುಬರ್ನೆಟ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ಸ್ ಡಿಕ್ಲೇರೇಟಿವ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್;
• ಕಸ್ಟಮೈಸ್ ಜೊತೆಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡುವುದು.

ಸೂಚನೆ. ಅನುವಾದ.: ನೀವು ಪ್ರಕಟಿಸಿದ ಲಿಂಕ್‌ಗಳ ಬ್ಲಾಕ್ ಅನ್ನು ಸಹ ಶಿಫಾರಸು ಮಾಡಬಹುದು ಸಂಪನ್ಮೂಲಗಳು ಉಪಯುಕ್ತತೆಯ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ, ಕಸ್ಟಮೈಜ್ ಕುರಿತು ಇತ್ತೀಚಿನ ವರದಿಗಳೊಂದಿಗೆ ವೀಡಿಯೊಗಳ ಸಂಗ್ರಹವನ್ನು ಅನುಸರಿಸಿ.

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

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• «ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಪರಿಕರಗಳು";
• «ಕುಬರ್ನೆಟ್ಸ್ 1.14: ಮುಖ್ಯ ನಾವೀನ್ಯತೆಗಳ ಅವಲೋಕನ";
• «ಆಮ್ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿ ಹೆಲ್ಮ್ ಶೃಂಗಸಭೆ 2019 ರ ಐದು ಪ್ರಮುಖ ಫಲಿತಾಂಶಗಳು";
• «ಕುಬರ್ನೆಟ್ಸ್ - ಹೆಲ್ಮ್‌ಗಾಗಿ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗೆ ಪ್ರಾಯೋಗಿಕ ಪರಿಚಯ».

ಮೂಲ: www.habr.com