ແນະນຳ Shell-operator: ການສ້າງຕົວປະຕິບັດການສຳລັບ Kubernetes ງ່າຍຂຶ້ນ

ມີບົດຄວາມກ່ຽວກັບ blog ຂອງພວກເຮົາເວົ້າກ່ຽວກັບ ຄວາມສາມາດຂອງຜູ້ປະກອບການໃນ Kubernetes ແລະແນວໃດ ຂຽນຕົວປະຕິບັດການງ່າຍດາຍຕົວທ່ານເອງ. ເວລານີ້ພວກເຮົາຢາກຈະນໍາສະເຫນີໃຫ້ທ່ານເອົາໃຈໃສ່ການແກ້ໄຂ Open Source ຂອງພວກເຮົາ, ເຊິ່ງໃຊ້ເວລາການສ້າງຕົວປະຕິບັດການໃນລະດັບທີ່ງ່າຍທີ່ສຸດ - ກວດເບິ່ງ shell-operator!

ເປັນຫຍັງ?

ແນວຄວາມຄິດຂອງ shell-operator ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ: ຈອງເຫດການຈາກວັດຖຸ Kubernetes, ແລະເມື່ອເຫດການເຫຼົ່ານີ້ໄດ້ຮັບ, ເປີດຕົວໂຄງການພາຍນອກ, ໃຫ້ຂໍ້ມູນກ່ຽວກັບເຫດການ:

ຄວາມຕ້ອງການສໍາລັບມັນເກີດຂື້ນໃນເວລາທີ່, ໃນລະຫວ່າງການປະຕິບັດງານຂອງກຸ່ມ, ວຽກງານຂະຫນາດນ້ອຍເລີ່ມປາກົດວ່າພວກເຮົາຕ້ອງການອັດຕະໂນມັດໃນທາງທີ່ຖືກຕ້ອງ. ວຽກງານນ້ອຍໆເຫຼົ່ານີ້ຖືກແກ້ໄຂໂດຍໃຊ້ bash scripts ງ່າຍດາຍ, ເຖິງແມ່ນວ່າ, ຕາມທີ່ທ່ານຮູ້, ມັນດີກວ່າທີ່ຈະຂຽນຕົວປະຕິບັດການໃນ Golang. ແນ່ນອນ, ການລົງທຶນໃນການພັດທະນາຢ່າງເຕັມທີ່ຂອງຜູ້ປະກອບການສໍາລັບແຕ່ລະວຽກງານຂະຫນາດນ້ອຍດັ່ງກ່າວຈະບໍ່ມີປະສິດທິພາບ.

ຜູ້ປະຕິບັດງານໃນ 15 ນາທີ

ໃຫ້ເບິ່ງຕົວຢ່າງຂອງສິ່ງທີ່ສາມາດອັດຕະໂນມັດໃນກຸ່ມ Kubernetes ແລະວິທີການທີ່ຕົວປະຕິບັດການແກະສາມາດຊ່ວຍໄດ້. ຕົວຢ່າງຈະເປັນດັ່ງຕໍ່ໄປນີ້: replicating ຄວາມລັບໃນການເຂົ້າເຖິງການລົງທະບຽນ docker.

Pods ທີ່ໃຊ້ຮູບພາບຈາກທະບຽນເອກະຊົນຕ້ອງມີຢູ່ໃນ manifest ການເຊື່ອມຕໍ່ກັບຄວາມລັບທີ່ມີຂໍ້ມູນສໍາລັບການເຂົ້າເຖິງການລົງທະບຽນ. ຄວາມລັບນີ້ຕ້ອງໄດ້ຮັບການສ້າງໃນແຕ່ລະ namespace ກ່ອນທີ່ຈະສ້າງ pods. ນີ້ສາມາດເຮັດໄດ້ດ້ວຍຕົນເອງ, ແຕ່ຖ້າພວກເຮົາຕັ້ງຄ່າສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວ, ຫຼັງຈາກນັ້ນ, namespace ສໍາລັບຄໍາຮ້ອງສະຫມັກຫນຶ່ງຈະກາຍເປັນຫຼາຍ. ແລະຖ້າບໍ່ມີ 2-3 ຄໍາຮ້ອງສະຫມັກ ... ຈໍານວນຂອງຄວາມລັບຈະກາຍເປັນຂະຫນາດໃຫຍ່ຫຼາຍ. ແລະອີກຢ່າງຫນຶ່ງກ່ຽວກັບຄວາມລັບ: ຂ້ອຍຢາກປ່ຽນລະຫັດເພື່ອເຂົ້າເຖິງການລົງທະບຽນເປັນບາງຄັ້ງຄາວ. ໃນທີ່ສຸດ, ການດໍາເນີນງານຄູ່ມື ເປັນການແກ້ໄຂ ບໍ່ມີປະສິດຕິຜົນຢ່າງສົມບູນ — ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ອັດ​ຕະ​ໂນ​ມັດ​ການ​ສ້າງ​ແລະ​ການ​ປັບ​ປຸງ​ຄວາມ​ລັບ​.

ອັດຕະໂນມັດແບບງ່າຍດາຍ

ໃຫ້ຂຽນສະຄຣິບແກະທີ່ແລ່ນທຸກໆ N ວິນາທີ ແລະກວດເບິ່ງ namespaces ເພື່ອເບິ່ງຄວາມລັບ, ແລະຖ້າບໍ່ມີຄວາມລັບ, ມັນຈະຖືກສ້າງຂື້ນ. ປະໂຫຍດຂອງການແກ້ໄຂນີ້ແມ່ນວ່າມັນຄ້າຍຄື script shell ໃນ cron - ເປັນວິທີການຄລາສສິກແລະເຂົ້າໃຈໄດ້ກັບທຸກຄົນ. ຂໍ້ເສຍແມ່ນວ່າໃນໄລຍະເວລາລະຫວ່າງການເປີດຕົວຂອງມັນສາມາດສ້າງ namespace ໃຫມ່ແລະສໍາລັບບາງເວລາມັນຈະຍັງຄົງຢູ່ໂດຍບໍ່ມີຄວາມລັບ, ເຊິ່ງຈະນໍາໄປສູ່ຄວາມຜິດພາດໃນການເປີດຕົວ pods.

ອັດຕະໂນມັດດ້ວຍ shell-operator

ເພື່ອໃຫ້ສະຄິບຂອງພວກເຮົາເຮັດວຽກຢ່າງຖືກຕ້ອງ, ການເປີດຕົວ cron ຄລາສສິກຈໍາເປັນຕ້ອງຖືກແທນທີ່ດ້ວຍການເປີດຕົວເມື່ອ namespace ຖືກເພີ່ມ: ໃນກໍລະນີນີ້, ທ່ານສາມາດສ້າງຄວາມລັບກ່ອນທີ່ຈະໃຊ້ມັນ. ໃຫ້ເບິ່ງວິທີການປະຕິບັດນີ້ໂດຍໃຊ້ shell-operator.

ທໍາອິດ, ໃຫ້ເບິ່ງ script ໄດ້. scripts ໃນເງື່ອນໄຂ shell-operator ເອີ້ນວ່າ hook. ທຸກໆ hook ເມື່ອແລ່ນດ້ວຍທຸງ --config ແຈ້ງໃຫ້ຜູ້ປະຕິບັດການແກະກ່ຽວກັບການຜູກມັດຂອງມັນ, i.e. ກ່ຽວກັບເຫດການໃດທີ່ມັນຄວນຈະຖືກເປີດຕົວ. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຈະນໍາໃຊ້ onKubernetesEvent:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

ມັນໄດ້ຖືກອະທິບາຍຢູ່ທີ່ນີ້ວ່າພວກເຮົາມີຄວາມສົນໃຈໃນການເພີ່ມເຫດການ (add) ວັດ​ຖຸ​ປະ​ເພດ​ namespace.

ໃນປັດຈຸບັນທ່ານຈໍາເປັນຕ້ອງເພີ່ມລະຫັດທີ່ຈະຖືກປະຕິບັດເມື່ອເຫດການເກີດຂື້ນ:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

ຍິ່ງໃຫຍ່! ຜົນໄດ້ຮັບແມ່ນ script ຂະຫນາດນ້ອຍ, ທີ່ສວຍງາມ. ເພື່ອ "ຟື້ນຟູ" ມັນ, ມີສອງຂັ້ນຕອນທີ່ຍັງເຫຼືອ: ກະກຽມຮູບພາບແລະເປີດຕົວໃນກຸ່ມ.

ການກະກຽມຮູບພາບທີ່ມີ hook ໄດ້

ຖ້າທ່ານເບິ່ງສະຄິບ, ທ່ານສາມາດເຫັນໄດ້ວ່າຄໍາສັ່ງຖືກນໍາໃຊ້ kubectl и jq. ນີ້ຫມາຍຄວາມວ່າຮູບພາບຕ້ອງມີສິ່ງຕໍ່ໄປນີ້: hook ຂອງພວກເຮົາ, shell-operator ທີ່ຈະຟັງເຫດການແລະດໍາເນີນການ hook, ແລະຄໍາສັ່ງທີ່ໃຊ້ໂດຍ hook (kubectl ແລະ jq). Hub.docker.com ມີຮູບພາບທີ່ກຽມພ້ອມແລ້ວ, ເຊິ່ງບັນຈຸ Shell-operator, kubectl ແລະ jq. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການເພີ່ມ hook ງ່າຍດາຍ Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

$ docker build -t registry.example.com/my-operator:v1 . 
$ docker push registry.example.com/my-operator:v1

ແລ່ນຢູ່ໃນກຸ່ມ

ໃຫ້ເບິ່ງທີ່ hook ອີກເທື່ອຫນຶ່ງແລະເວລານີ້ຂຽນສິ່ງທີ່ປະຕິບັດແລະສິ່ງທີ່ມັນປະຕິບັດໃນກຸ່ມ:

1. ຈອງເຫດການການສ້າງ namespace;
2. ສ້າງຄວາມລັບໃນ namespaces ອື່ນນອກເຫນືອຈາກບ່ອນທີ່ມັນຖືກເປີດຕົວ.

ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ຝັກ​ທີ່​ຮູບ​ພາບ​ຂອງ​ພວກ​ເຮົາ​ຈະ​ໄດ້​ຮັບ​ການ​ເປີດ​ຕົວ​ຕ້ອງ​ມີ​ການ​ອະ​ນຸ​ຍາດ​ໃຫ້​ເຮັດ​ການ​ປະ​ຕິ​ບັດ​ເຫຼົ່າ​ນີ້​. ນີ້ສາມາດເຮັດໄດ້ໂດຍການສ້າງບັນຊີ ServiceAccount ຂອງທ່ານເອງ. ການອະນຸຍາດຕ້ອງເຮັດໃນຮູບແບບຂອງ ClusterRole ແລະ ClusterRoleBinding, ເພາະວ່າ ພວກເຮົາສົນໃຈວັດຖຸຈາກກຸ່ມທັງໝົດ.

ຄໍາອະທິບາຍສຸດທ້າຍໃນ YAML ຈະມີລັກສະນະເຊັ່ນນີ້:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

ທ່ານ​ສາ​ມາດ​ເປີດ​ຮູບ​ພາບ​ປະ​ກອບ​ເປັນ​ການ​ນໍາ​ໃຊ້​ງ່າຍ​ດາຍ​:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

ເພື່ອຄວາມສະດວກ, namespace ແຍກຕ່າງຫາກແມ່ນຖືກສ້າງຂຶ້ນບ່ອນທີ່ shell-operator ຈະຖືກເປີດຕົວແລະ manifests ທີ່ສ້າງຂຶ້ນຈະຖືກນໍາໃຊ້:

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

ນັ້ນແມ່ນທັງຫມົດ: shell-operator ຈະເລີ່ມຕົ້ນ, ລົງທະບຽນກັບເຫດການການສ້າງ namespace ແລະດໍາເນີນການ hook ເມື່ອຈໍາເປັນ.

ດັ່ງນັ້ນ, script shell ງ່າຍໆກາຍເປັນຕົວປະຕິບັດການທີ່ແທ້ຈິງສໍາລັບ Kubernetes ແລະເຮັດວຽກເປັນສ່ວນຫນຶ່ງຂອງກຸ່ມ. ແລະທັງຫມົດນີ້ໂດຍບໍ່ມີຂະບວນການສະລັບສັບຊ້ອນຂອງການພັດທະນາຜູ້ປະກອບການໃນ Golang:

ມີຕົວຢ່າງອີກອັນໜຶ່ງກ່ຽວກັບເລື່ອງນີ້...

ພວກເຮົາຈະເປີດເຜີຍຄວາມຫມາຍຂອງມັນໃຫ້ລະອຽດຕື່ມຢູ່ໃນຫນຶ່ງໃນສິ່ງພິມຕໍ່ໄປນີ້.

ການກັ່ນຕອງ

ການຕິດຕາມວັດຖຸແມ່ນດີ, ແຕ່ມັກຈະມີຄວາມຕ້ອງການທີ່ຈະຕອບສະຫນອງຕໍ່ ການປ່ຽນແປງບາງຄຸນສົມບັດວັດຖຸ, ສໍາລັບການຍົກຕົວຢ່າງ, ການປ່ຽນແປງຈໍານວນຂອງ replicas ໃນ Deployment ຫຼືການປ່ຽນແປງປ້າຍວັດຖຸ.

ເມື່ອເຫດການມາຮອດ, shell-operator ໄດ້ຮັບ JSON manifest ຂອງວັດຖຸ. ພວກເຮົາສາມາດເລືອກຄຸນສົມບັດທີ່ພວກເຮົາສົນໃຈໃນ JSON ນີ້ແລະດໍາເນີນການ hook ໄດ້ ພຽງແຕ່ ເມື່ອພວກເຂົາປ່ຽນແປງ. ມີພາກສະຫນາມສໍາລັບການນີ້ jqFilter, ບ່ອນທີ່ທ່ານຈໍາເປັນຕ້ອງລະບຸການສະແດງອອກ jq ທີ່ຈະຖືກນໍາໃຊ້ກັບ JSON manifest.

ຕົວຢ່າງ, ເພື່ອຕອບສະຫນອງການປ່ຽນແປງໃນປ້າຍຊື່ສໍາລັບ Deployment objects, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກັ່ນຕອງພາກສະຫນາມ labels ອອກຈາກພາກສະຫນາມ metadata. config ຈະ​ເປັນ​ດັ່ງ​ນີ້​:

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

ການສະແດງອອກ jqFilter ນີ້ປ່ຽນ JSON ຍາວຂອງ Deployment ໃຫ້ເປັນ JSON ສັ້ນທີ່ມີປ້າຍຊື່:

shell-operator ຈະແລ່ນ hook ເມື່ອ JSON ສັ້ນນີ້ປ່ຽນແປງ, ແລະການປ່ຽນແປງຄຸນສົມບັດອື່ນໆຈະຖືກລະເລີຍ.

ບໍລິບົດການເປີດຕົວ Hook

ການຕັ້ງຄ່າ hook ຊ່ວຍໃຫ້ທ່ານສາມາດລະບຸຕົວເລືອກຫຼາຍຢ່າງສໍາລັບເຫດການ - ຕົວຢ່າງ, 2 ທາງເລືອກສໍາລັບເຫດການຈາກ Kubernetes ແລະ 2 ຕາຕະລາງ:

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

A digression ຂະຫນາດນ້ອຍ: ແມ່ນ, shell-operator ສະຫນັບສະຫນູນ ແລ່ນສະຄຣິບແບບ crontab. ລາຍລະອຽດເພີ່ມເຕີມສາມາດພົບໄດ້ໃນ ເອກະສານ.

ເພື່ອຈໍາແນກວ່າເປັນຫຍັງ hook ໄດ້ຖືກເປີດຕົວ, shell-operator ສ້າງໄຟລ໌ຊົ່ວຄາວແລະຜ່ານເສັ້ນທາງໄປຫາມັນຢູ່ໃນຕົວແປຂອງ hook. BINDING_CONTEXT_TYPE. ໄຟລ໌ປະກອບມີຄໍາອະທິບາຍ JSON ຂອງເຫດຜົນສໍາລັບການແລ່ນ hook. ຕົວຢ່າງ, ທຸກໆ 10 ນາທີ hook ຈະແລ່ນດ້ວຍເນື້ອຫາຕໍ່ໄປນີ້:

[{ "binding": "every 10 min"}]

... ແລະໃນວັນຈັນມັນຈະເລີ່ມຕົ້ນດ້ວຍນີ້:

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

ໄປ onKubernetesEvent ຈະມີຕົວກະຕຸ້ນ JSON ຫຼາຍຂຶ້ນ, ເພາະວ່າ ມັນປະກອບດ້ວຍຄໍາອະທິບາຍຂອງວັດຖຸ:

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

ເນື້ອໃນຂອງທົ່ງນາສາມາດເຂົ້າໃຈໄດ້ຈາກຊື່ຂອງເຂົາເຈົ້າ, ແລະລາຍລະອຽດເພີ່ມເຕີມສາມາດອ່ານໄດ້ໃນ ເອກະສານ. ຕົວຢ່າງຂອງການໄດ້ຮັບຊື່ຊັບພະຍາກອນຈາກພາກສະຫນາມ resourceName ການນໍາໃຊ້ jq ໄດ້ຖືກສະແດງໃຫ້ເຫັນແລ້ວໃນ hook ທີ່ replicates ຄວາມລັບ:

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

ທ່ານສາມາດໄດ້ຮັບພາກສະຫນາມອື່ນໆໃນລັກສະນະທີ່ຄ້າຍຄືກັນ.

ຈະເປັນແນວໃດຕໍ່ໄປ?

ໃນ repository ໂຄງການ, ໃນ /example directory, ມີຕົວຢ່າງຂອງ hooks ທີ່ພ້ອມທີ່ຈະດໍາເນີນການຢູ່ໃນກຸ່ມ. ໃນເວລາທີ່ຂຽນ hooks ຂອງທ່ານເອງ, ທ່ານສາມາດນໍາໃຊ້ໃຫ້ເຂົາເຈົ້າເປັນພື້ນຖານ.

ມີການສະຫນັບສະຫນູນສໍາລັບການເກັບກໍາ metrics ໂດຍໃຊ້ Prometheus - metrics ທີ່ມີຢູ່ແມ່ນໄດ້ອະທິບາຍຢູ່ໃນພາກ ມທ.

ດັ່ງທີ່ເຈົ້າອາດຈະຄາດເດົາໄດ້, shell-operator ຖືກຂຽນໄວ້ໃນ Go ແລະແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດ Open Source (Apache 2.0). ພວກເຮົາຈະຂໍຂອບໃຈສໍາລັບການຊ່ວຍເຫຼືອດ້ານການພັດທະນາໃດໆ ໂຄງ​ການ​ກ່ຽວ​ກັບ GitHub​: ແລະດາວ, ແລະບັນຫາ, ແລະດຶງຄໍາຮ້ອງຂໍ.

ການຍົກຜ້າມ່ານຂອງຄວາມລັບ, ພວກເຮົາຍັງຈະແຈ້ງໃຫ້ທ່ານຮູ້ວ່າ shell-operator ແມ່ນ ຂະຫນາດນ້ອຍ ສ່ວນຫນຶ່ງຂອງລະບົບຂອງພວກເຮົາທີ່ສາມາດຮັກສາ add-ons ຕິດຕັ້ງຢູ່ໃນກຸ່ມ Kubernetes ໄດ້ທັນສະໄຫມແລະດໍາເນີນການອັດຕະໂນມັດຕ່າງໆ. ອ່ານເພີ່ມເຕີມກ່ຽວກັບລະບົບນີ້ ບອກ ໃນວັນຈັນທີ່ HighLoad++ 2019 ທີ່ St. Petersburg - ພວກເຮົາຈະເຜີຍແຜ່ວິດີໂອ ແລະຂໍ້ຄວາມຖອດຈາກສຽງຂອງບົດລາຍງານນີ້ໃນໄວໆນີ້.

ພວກເຮົາມີແຜນການທີ່ຈະເປີດສ່ວນທີ່ເຫຼືອຂອງລະບົບນີ້: addon-operator ແລະການເກັບກໍາຂອງພວກເຮົາຂອງ hooks ແລະໂມດູນ. ໂດຍວິທີທາງການ, addon-operator ແມ່ນແລ້ວ ມີຢູ່ໃນ GitHub, ແຕ່ເອກະສານສໍາລັບມັນຍັງຢູ່ໃນວິທີການ. ການປ່ອຍຕົວຂອງການເກັບກໍາໂມດູນໄດ້ຖືກວາງແຜນໄວ້ສໍາລັບລະດູຮ້ອນ.

ຕິດຕາມເບິ່ງ!

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ຜູ້ປະກອບການສໍາລັບ Kubernetes: ວິທີການດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງລັດ"
• «ການຂຽນຕົວປະຕິບັດການສໍາລັບ Kubernetes ໃນ Golang"
• «ແນະນຳປລັກອິນໃໝ່ສຳລັບ Grafana - Statusmap panel"
• «ແນະນໍາ loghouse - ລະບົບແຫຼ່ງເປີດສໍາລັບການເຮັດວຽກກັບບັນທຶກໃນ Kubernetes"
• «ພວກເຮົານຳສະເໜີ dapp ຢ່າງເປັນທາງການ - ປະໂຫຍດຂອງ DevOps ສຳລັບການບຳລຸງຮັກສາ CI/CD".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com