ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹಳೆಯ ವೈಶಿಷ್ಟ್ಯದ ಶಾಖೆಯನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ

ಹಾಯ್! ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆ (ಅಕಾ ಡಿಪ್ಲೋಯ್ ಪೂರ್ವವೀಕ್ಷಣೆ, ವಿಮರ್ಶೆ ಅಪ್ಲಿಕೇಶನ್) - ಇದು ಮಾಸ್ಟರ್ ಶಾಖೆಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ ಮಾತ್ರ, ಆದರೆ ಪ್ರತಿ ಒಂದು ಅನನ್ಯ URL ಗೆ ವಿನಂತಿಯನ್ನು ಎಳೆಯುತ್ತದೆ. ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಕೋಡ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂದು ನೀವು ಪರಿಶೀಲಿಸಬಹುದು; ವೈಶಿಷ್ಟ್ಯವನ್ನು ಇತರ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಅಥವಾ ಉತ್ಪನ್ನ ತಜ್ಞರಿಗೆ ತೋರಿಸಬಹುದು. ನೀವು ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ, ಹಳೆಯ ಕೋಡ್‌ಗಾಗಿ ಪ್ರತಿ ಹೊಸ ಕಮಿಟ್ ಪ್ರಸ್ತುತ ನಿಯೋಜನೆಯನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಕೋಡ್‌ಗಾಗಿ ಹೊಸ ನಿಯೋಜನೆಯನ್ನು ಹೊರತರಲಾಗುತ್ತದೆ. ನೀವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ವಿಲೀನಗೊಳಿಸಿದಾಗ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸಬಹುದು. ನಿಮಗೆ ಇನ್ನು ಮುಂದೆ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳು ಇನ್ನೂ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿವೆ.

ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಗಳನ್ನು ಮಾಡುವ ಒಂದು ವಿಧಾನವೆಂದರೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಬಳಸುವುದು. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಉತ್ಪಾದನಾ ಸಂರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

ವೈಶಿಷ್ಟ್ಯದ ಶಾಖೆಗಾಗಿ, ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಅದರ ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ ರಚಿಸಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಪುಲ್ ವಿನಂತಿ ಸಂಖ್ಯೆ) ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಪೂರ್ವಪ್ರತ್ಯಯ/ಪೋಸ್ಟ್‌ಫಿಕ್ಸ್ (ಉದಾಹರಣೆಗೆ, -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

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

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ನೀವು ಓದಬಹುದು ಇಲ್ಲಿ и ಇಲ್ಲಿ.

ಪ್ರೇರಣೆ

ನಿರಂತರ ಏಕೀಕರಣದೊಂದಿಗೆ ವಿಶಿಷ್ಟವಾದ ಪುಲ್ ವಿನಂತಿಯ ಜೀವನಚಕ್ರವನ್ನು ನೋಡೋಣ (continuous integration):

1. ನಾವು ಶಾಖೆಗೆ ಹೊಸ ಬದ್ಧತೆಯನ್ನು ತಳ್ಳುತ್ತೇವೆ.
2. ನಿರ್ಮಾಣದಲ್ಲಿ, ಲಿಂಟರ್‌ಗಳು ಮತ್ತು/ಅಥವಾ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ.
3. ಕುಬರ್ನೆಟ್ಸ್ ಪುಲ್ ವಿನಂತಿಯ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಹಾರಾಡುತ್ತ ರಚಿಸಲಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಅದರ ಸಂಖ್ಯೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದ ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ).
4. kubectl ಅನ್ವಯಿಸುವಿಕೆಯನ್ನು ಬಳಸಿ, ಸಂರಚನೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ (ನಿಯೋಜನೆ).
5. ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಸ್ಟರ್ ಶಾಖೆಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಲಾಗಿದೆ.

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

ಹೇಗೆ ಬಳಸುವುದು

ಕೆಳಗಿನ ಆಜ್ಞೆಯೊಂದಿಗೆ ಯೋಜನೆಯನ್ನು ಸ್ಥಾಪಿಸಿ:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

ಕೆಳಗಿನ ವಿಷಯದೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಮೂಲಕ ಸ್ಥಾಪಿಸಿ kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

ನಿಯತಾಂಕ namespaceSubstring ಇತರ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಿಂದ ಪುಲ್ ವಿನಂತಿಗಳಿಗಾಗಿ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಅಗತ್ಯವಿದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲಸ್ಟರ್ ಈ ಕೆಳಗಿನ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, ನಂತರ ಅಳಿಸುವಿಕೆಗೆ ಅಭ್ಯರ್ಥಿಗಳು ಆಗಿರುತ್ತಾರೆ habr-back-end-pr-17, habr-back-end-pr-33.

ನಿಯತಾಂಕ ನಂತರದಿನಗಳು ವಿಥೌಟ್ ಡಿಪ್ಲೋಯ್ ಹಳೆಯ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಅಳಿಸಲು ಅಗತ್ಯವಿದೆ. ಉದಾಹರಣೆಗೆ, ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ರಚಿಸಿದರೆ 3 дня 1 час ಹಿಂದೆ, ಮತ್ತು ನಿಯತಾಂಕವು ಸೂಚಿಸುತ್ತದೆ 3 дня, ಈ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ. ನೇಮ್‌ಸ್ಪೇಸ್ ರಚಿಸಿದರೆ ಅದು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿಯೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ 2 дня 23 часа ಹಿಂದೆ, ಮತ್ತು ನಿಯತಾಂಕವು ಸೂಚಿಸುತ್ತದೆ 3 дня, ಈ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಅಳಿಸಲಾಗುವುದಿಲ್ಲ.

ಇನ್ನೂ ಒಂದು ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ, ಎಲ್ಲಾ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಎಷ್ಟು ಬಾರಿ ಸ್ಕ್ಯಾನ್ ಮಾಡುವುದು ಮತ್ತು ನಿಯೋಜನೆಯಿಲ್ಲದೆ ದಿನಗಳವರೆಗೆ ಪರಿಶೀಲಿಸುವುದು ಇದಕ್ಕೆ ಕಾರಣವಾಗಿದೆ - ಪ್ರತಿ ನಿಮಿಷಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು ಸಮಾನವಾಗಿರುತ್ತದೆ 30 минутам.

ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಿಮಗೆ ಅಗತ್ಯವಿರುತ್ತದೆ:

1. ಡಾಕರ್ ಪ್ರತ್ಯೇಕ ಪರಿಸರದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು.
2. ಮಿನಿಕೂಬ್ ಸ್ಥಳೀಯವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬೆಳೆಸುತ್ತದೆ.
3. kubectl — ಕ್ಲಸ್ಟರ್ ನಿರ್ವಹಣೆಗಾಗಿ ಕಮಾಂಡ್ ಲೈನ್ ಇಂಟರ್ಫೇಸ್.

ನಾವು ಸ್ಥಳೀಯವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬೆಳೆಸುತ್ತೇವೆ:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

ಸೂಚಿಸಿ kubectl ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸ್ಥಳೀಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಳಸಿ:

$ kubectl config use-context minikube
Switched to context "minikube".

ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕಾಗಿ ಸಂರಚನೆಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

ಉತ್ಪಾದನಾ ಸಂರಚನೆಗಳನ್ನು ಹಳೆಯ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿರುವುದರಿಂದ ಮತ್ತು ನಮ್ಮ ಹೊಸದಾಗಿ ಬೆಳೆದ ಕ್ಲಸ್ಟರ್ ಅವುಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿರುವುದರಿಂದ, ನಾವು ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ IS_DEBUG ಮೇಲೆ true. ಈ ಮೌಲ್ಯದೊಂದಿಗೆ ಪ್ಯಾರಾಮೀಟರ್ afterDaysWithoutDeploy ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ನಿಯೋಜಿಸದೆ ದಿನಗಳವರೆಗೆ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ, ಸಬ್‌ಸ್ಟ್ರಿಂಗ್ ಸಂಭವಿಸುವುದಕ್ಕಾಗಿ ಮಾತ್ರ (-pr-).

ನೀವು ಆನ್ ಆಗಿದ್ದರೆ Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

ನೀವು ಆನ್ ಆಗಿದ್ದರೆ macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

ಯೋಜನೆಯನ್ನು ಸ್ಥಾಪಿಸುವುದು:

$ kubectl apply -f stale-feature-branch-production-configs.yml

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲ ಕಾಣಿಸಿಕೊಂಡಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಆಪರೇಟರ್ ಕಾಣಿಸಿಕೊಂಡಿದ್ದಾರೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

ನೀವು ಅದರ ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ಅದು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಿದ್ಧವಾಗಿದೆ StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

ನಾವು ರೆಡಿಮೇಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ fixtures (ಕ್ಲಸ್ಟರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾಡೆಲಿಂಗ್ ಮಾಡಲು ಸಿದ್ಧ-ಸಿದ್ಧ ಸಂರಚನೆಗಳು) ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

ಸಬ್‌ಸ್ಟ್ರಿಂಗ್‌ನೊಂದಿಗೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಹುಡುಕಲು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಸೂಚಿಸುತ್ತವೆ -pr- ಒಮ್ಮೆ ಒಳಗೆ 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

ಆಪರೇಟರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದ್ದಾರೆ ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಿದ್ಧರಾಗಿದ್ದಾರೆ:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

ಸ್ಥಾಪಿಸಿ fixtures, ಎರಡು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದೆ (project-pr-1, project-pr-2) ಮತ್ತು ಅವರು deployments, services, ingress, ಮತ್ತು ಇತ್ಯಾದಿ:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

ಮೇಲಿನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ರಚಿಸಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

ನಾವು ಸೇರಿಸಿರುವುದರಿಂದ debug, ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು project-pr-1 и project-pr-2, ಆದ್ದರಿಂದ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ಎಲ್ಲಾ ಇತರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಕ್ಷಣವೇ ಅಳಿಸಬೇಕಾಗುತ್ತದೆ afterDaysWithoutDeploy. ಆಪರೇಟರ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಕಾಣಬಹುದು:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

ಸಂಪನ್ಮೂಲಗಳ ಲಭ್ಯತೆಯನ್ನು ನೀವು ಪರಿಶೀಲಿಸಿದರೆ, ಅವರು ಸ್ಥಿತಿಯಲ್ಲಿರುತ್ತಾರೆ Terminating (ಅಳಿಸುವಿಕೆಯ ಪ್ರಕ್ರಿಯೆ) ಅಥವಾ ಈಗಾಗಲೇ ಅಳಿಸಲಾಗಿದೆ (ಕಮಾಂಡ್ ಔಟ್ಪುಟ್ ಖಾಲಿಯಾಗಿದೆ).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

ನೀವು ಸೃಷ್ಟಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು fixtures ಹಲವಾರು ಬಾರಿ ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಪರ್ಯಾಯಗಳು

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಆಪರೇಟರ್ ಬದಲಿಗೆ ಏನು ಮಾಡಬಹುದು? ಹಲವಾರು ವಿಧಾನಗಳಿವೆ, ಅವೆಲ್ಲವೂ ಅಪೂರ್ಣವಾಗಿವೆ (ಮತ್ತು ಅವರ ನ್ಯೂನತೆಗಳು ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿವೆ), ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಗೆ ಯಾವುದು ಉತ್ತಮ ಎಂದು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ:

1. ಮಾಸ್ಟರ್ ಶಾಖೆಯ ನಿರಂತರ ಏಕೀಕರಣ ನಿರ್ಮಾಣದ ಸಮಯದಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯನ್ನು ಅಳಿಸಿ.

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

2. ವೆಬ್‌ಹೂಕ್‌ಗಳನ್ನು ಬಳಸುವುದು (ಉದಾಹರಣೆ).

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

3. ಬರೆಯಲು ಕ್ರೋನ್ಜಾಬ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸೇರಿಸಿ.

   • ಬರವಣಿಗೆ ಮತ್ತು ಬೆಂಬಲಕ್ಕಾಗಿ ಸಮಯವನ್ನು ಕಳೆಯಿರಿ.
   • ಆಪರೇಟರ್ ಈಗಾಗಲೇ ಇದೇ ಶೈಲಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ, ದಾಖಲಿಸಲಾಗಿದೆ ಮತ್ತು ಬೆಂಬಲಿತವಾಗಿದೆ.

ಲೇಖನದ ಬಗ್ಗೆ ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು. Github ನಲ್ಲಿ ಯೋಜನೆಗೆ ಲಿಂಕ್ ಮಾಡಿ.

ಮೂಲ: www.habr.com