Kubernetes ішіндегі Кафка кластері үшін сәйкес өлшемді анықтау

Ескерту. аударма: Бұл мақалада Banzai Cloud Кафканы Kubernetes ішінде пайдалануды жеңілдету үшін оның реттелетін құралдарын қалай пайдалануға болатыны туралы мысалмен бөліседі. Төмендегі нұсқаулар инфрақұрылымның оңтайлы өлшемін анықтау және қажетті өткізу қабілетіне қол жеткізу үшін Кафканың өзін конфигурациялау жолын көрсетеді.

Apache Kafka - сенімді, масштабталатын және жоғары өнімді нақты уақыттағы ағындық жүйелерді жасауға арналған таратылған ағындық платформа. Оның әсерлі мүмкіндіктерін Kubernetes көмегімен кеңейтуге болады. Бұл үшін біз дамыттық Ашық бастапқы коды Кафка операторы және құрал деп аталады Супертүтіктер. Олар Кафканы Kubernetes жүйесінде іске қосуға және оның брокер конфигурациясын дәл баптау, қайта теңестіру арқылы метрикаға негізделген масштабтау, сөре туралы хабардар болу, «жұмсақ» сияқты әртүрлі мүмкіндіктерін пайдалануға мүмкіндік береді. (әдемі) жаңартуларды шығару және т.б.

Кластеріңізде Supertubes қолданбасын қолданып көріңіз:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Немесе хабарласыңыз құжаттама. Сондай-ақ, Кафканың кейбір мүмкіндіктері туралы оқуға болады, олармен жұмыс Supertubes және Кафка операторы арқылы автоматтандырылған. Біз олар туралы блогта жазғанбыз:

• О жоқ! Kubernetes үшін тағы бір Кафка операторы;
• Prometheus метрикасына негізделген Кафканы бақылаңыз және басқарыңыз;
• Кубернетестегі Кафка туралы хабардар болу;
• Apache Кафканы Istio арқылы іске қосу - эталон;
• Кафка операторымен пайдаланушы аутентификацияланған және басқарылатын кластерлерге қол жеткізу;
• Kubernetes жүйесінде Кафканы жылжымалы жаңарту және динамикалық конфигурациялау;
• Кафка үшін өкіл хаттама сүзгісі, тор.

Kubernetes жүйесінде Кафка кластерін орналастыруды шешкен кезде, сіз негізгі инфрақұрылымның оңтайлы өлшемін анықтау және өткізу қабілеттілігі талаптарын қанағаттандыру үшін Кафка конфигурациясын дәл баптау қажеттілігіне тап болуыңыз мүмкін. Әрбір брокердің максималды өнімділігі жад, процессор, диск жылдамдығы, желінің өткізу қабілеті және т.б. сияқты негізгі инфрақұрылым компоненттерінің өнімділігімен анықталады.

Ең дұрысы, брокер конфигурациясы барлық инфрақұрылым элементтері максималды мүмкіндіктеріне дейін пайдаланылатындай болуы керек. Дегенмен, нақты өмірде бұл орнату өте күрделі. Пайдаланушылар бір немесе екі құрамдас бөлікті (диск, жад немесе процессор) барынша пайдалану үшін брокерлерді конфигурациялауы ықтимал. Жалпы айтқанда, брокер оның конфигурациясы ең баяу құрамдас бөлікті толық көлемде пайдалануға мүмкіндік бергенде максималды өнімділікті көрсетеді. Осылайша біз бір брокер көтере алатын жүктеме туралы шамамен түсінік ала аламыз.

Теориялық тұрғыдан біз берілген жүктемені өңдеуге қажетті брокерлер санын да бағалай аламыз. Дегенмен, іс жүзінде әртүрлі деңгейлерде конфигурация опцияларының көптігі сонша, белгілі бір конфигурацияның ықтимал өнімділігін бағалау өте қиын (мүмкін емес болса). Басқаша айтқанда, кейбір берілген өнімділікке негізделген конфигурацияны жоспарлау өте қиын.

Supertubes пайдаланушылары үшін біз әдетте келесі тәсілді қолданамыз: біз кейбір конфигурациядан бастаймыз (инфрақұрылым + параметрлер), содан кейін оның өнімділігін өлшейміз, брокер параметрлерін реттейміз және процесті қайтадан қайталаймыз. Бұл инфрақұрылымның ең баяу құрамдас бөлігі толығымен пайдаланылғанша орын алады.

Осылайша, біз кластерге белгілі бір жүктемені өңдеу үшін қанша брокер қажет екендігі туралы нақтырақ түсінік аламыз (брокерлер саны басқа факторларға да байланысты, мысалы, тұрақтылықты қамтамасыз ету үшін хабарлама репликаларының ең аз саны, бөлімдер саны. жетекшілер және т.б.). Бұған қоса, біз қандай инфрақұрылым құрамдастары тік масштабтауды қажет ететінін түсінеміз.

Бұл мақалада бастапқы конфигурациялардағы ең баяу құрамдас бөліктерден барынша пайда алу және Кафка кластерінің өткізу қабілетін өлшеу үшін біз жасайтын қадамдар туралы айтылады. Жоғары төзімді конфигурация үшін кемінде үш жұмыс істейтін брокер қажет (min.insync.replicas=3), үш түрлі қолжетімділік аймағына бөлінген. Kubernetes инфрақұрылымын конфигурациялау, масштабтау және бақылау үшін гибридті бұлттарға арналған контейнерлерді басқару платформасын қолданамыз - Құбыр. Ол жергілікті (жалаңаш металл, VMware) және бұлттардың бес түрін (Alibaba, AWS, Azure, Google, Oracle), сондай-ақ олардың кез келген комбинациясын қолдайды.

Кафка кластерінің инфрақұрылымы мен конфигурациясы туралы ойлар

Төменде келтірілген мысалдар үшін бұлттық провайдер ретінде AWS және Kubernetes дистрибуциясы ретінде EKS таңдадық. Осыған ұқсас конфигурацияны қолдану арқылы жүзеге асыруға болады PKE - CNCF сертификатталған Banzai Cloud ұсынған Kubernetes дистрибуциясы.

диск

Amazon әртүрлі ұсыныстарды ұсынады EBS көлемінің түрлері. Негізінде gp2 и io1 жоғары өткізу қабілеттілігін қамтамасыз ету үшін SSD дискілері бар gp2 жинақталған несиелерді тұтынады (I/O кредиттері), сондықтан біз түрін таңдадық io1, ол тұрақты жоғары өткізу қабілеттілігін ұсынады.

Дана түрлері

Кафканың өнімділігі операциялық жүйенің бет кэшіне өте тәуелді, сондықтан бізге брокерлер (JVM) және бет кэші үшін жеткілікті жады бар даналар қажет. Мысал c5.2x үлкен - жақсы бастама, өйткені оның жады 16 ГБ және EBS-пен жұмыс істеу үшін оңтайландырылған. Оның кемшілігі - ол әр 30 сағат сайын 24 минуттан аспайтын максималды өнімділікті қамтамасыз ете алады. Жұмыс жүктемеңіз ұзақ уақыт бойы ең жоғары өнімділікті қажет етсе, басқа дана түрлерін қарастырғыңыз келуі мүмкін. Біз дәл осылай жасадық, тоқтап қалдық c5.4x үлкен. Ол максималды өткізу қабілеттілігін қамтамасыз етеді 593,75 Мб/с. EBS көлемінің максималды өткізу қабілеті io1 данаға қарағанда жоғары c5.4x үлкен, сондықтан инфрақұрылымның ең баяу элементі осы дана түрінің енгізу/шығару қабілеті болуы мүмкін (оны біздің жүктеме сынақтары да растауы керек).

Желі

Желінің өткізу қабілеті VM данасы мен дискінің өнімділігімен салыстырғанда жеткілікті үлкен болуы керек, әйтпесе желі тар жолға айналады. Біздің жағдайда желілік интерфейс c5.4x үлкен 10 Гб/с дейінгі жылдамдықты қолдайды, бұл VM данасының енгізу/шығару өткізу қабілетінен айтарлықтай жоғары.

Брокерді орналастыру

Орталық процессор, жад, желі және диск ресурстары үшін басқа процестермен бәсекелес болмас үшін брокерлер арнайы түйіндерге орналастырылуы керек (Kubernetes бағдарламасында жоспарланған).

Java нұсқасы

Логикалық таңдау Java 11 болып табылады, себебі ол JVM брокер жұмыс істеп тұрған контейнерге қол жетімді процессорлар мен жадты дұрыс анықтайды деген мағынада Docker бағдарламасымен үйлесімді. Процессор шектеулерінің маңызды екенін біле отырып, JVM GC және JIT ағындарының санын ішкі және мөлдір түрде орнатады. Біз Кафка бейнесін қолдандық banzaicloud/kafka:2.13-2.4.0, оған Java 2.4.0 жүйесіндегі Кафка 2.13 (Scala 11) нұсқасы кіреді.

Егер сіз Kubernetes-те Java/JVM туралы көбірек білгіңіз келсе, келесі жазбаларымызды қараңыз:

• Неліктен менің Java қолданбам OOMKilled;
• Java 10 қолданбалары үшін контейнерлерді қалай дұрыс өлшеуге болады.

Брокер жады параметрлері

Брокер жадын конфигурациялаудың екі негізгі аспектісі бар: JVM және Kubernetes подъездінің параметрлері. JVM өз жадында орналасқан Java метакеңістігіне және Кафка белсенді пайдаланатын операциялық жүйе бетінің кэшіне орын болуы үшін подкаст үшін орнатылған жад шегі максималды үйме өлшемінен үлкен болуы керек. Тесттерімізде параметрлері бар Кафка брокерлерін іске қостық -Xmx4G -Xms2G, және қосқыш үшін жад шегі болды 10 Gi. JVM үшін жад параметрлерін пайдалану арқылы автоматты түрде алуға болатынын ескеріңіз -XX:MaxRAMPercentage и -X:MinRAMPercentage, подвод үшін жад шегіне негізделген.

Брокер процессорының параметрлері

Жалпы айтқанда, Кафка пайдаланатын ағындар санын көбейту арқылы параллелизмді арттыру арқылы өнімділікті жақсартуға болады. Кафка үшін неғұрлым көп процессорлар болса, соғұрлым жақсы. Тестімізде біз 6 процессордың шегінен бастадық және біртіндеп (итерациялар арқылы) олардың санын 15-ке жеткіздік. Сонымен қатар, біз num.network.threads=12 брокер параметрлерінде желіден деректерді алатын және оны жіберетін ағындардың санын көбейту үшін. Ізбасар брокерлер көшірмелерді тез ала алмайтынын бірден анықтап, олар көтерілді num.replica.fetchers 4-ке дейін ізбасар брокерлерінің көшбасшылардың хабарламаларын қайталау жылдамдығын арттыру.

Жүктеме жасау құралы

Таңдалған жүктеме генераторының Кафка кластері (салыстырмалы) максималды жүктемеге жеткенге дейін қуаты таусылмауын қамтамасыз ету керек. Басқаша айтқанда, жүктемені генерациялау құралының мүмкіндіктерін алдын ала бағалауды жүргізу, сонымен қатар оған процессорлар мен жадының жеткілікті саны бар дана түрлерін таңдау қажет. Бұл жағдайда біздің құралымыз Кафка кластері көтере алатындан көп жүктемені шығарады. Көптеген тәжірибелерден кейін біз үш данаға тоқтадық c5.4x үлкен, олардың әрқайсысында генератор жұмыс істеп тұрды.

Салыстыру

Тиімділікті өлшеу келесі кезеңдерді қамтитын қайталанатын процесс:

• инфрақұрылымды орнату (EKS кластері, Кафка кластері, жүктемені генерациялау құралы, сонымен қатар Prometheus және Grafana);
• жинақталған өнімділік көрсеткіштеріндегі кездейсоқ ауытқуларды сүзгілеу үшін белгілі бір кезеңге жүктемені генерациялау;
• брокердің инфрақұрылымы мен конфигурациясын бақыланатын өнімділік көрсеткіштері негізінде реттеу;
• Кафка кластерінің өткізу қабілетінің қажетті деңгейіне жеткенше процесті қайталау. Сонымен бірге ол дәйекті түрде қайталанатын және өткізу қабілеттілігіндегі ең аз өзгерістерді көрсетуі керек.

Келесі бөлім сынақ кластерін салыстыру процесі кезінде орындалған қадамдарды сипаттайды.

Құралдар

Негізгі конфигурацияны жылдам орналастыру, жүктемелерді жасау және өнімділікті өлшеу үшін келесі құралдар пайдаланылды:

• Банзай бұлтты құбыры Amazon-дан EKS кластерін ұйымдастыру үшін c Прометей (Кафка мен инфрақұрылым көрсеткіштерін жинау үшін) және Графана (осы көрсеткіштерді визуализациялау үшін). Біз тиімді пайдаландық біріктірілген в Құбыр федеративті мониторинг, орталықтандырылған журналдарды жинау, осалдықтарды сканерлеу, апатты қалпына келтіру, кәсіпорын деңгейіндегі қауіпсіздік және т.б. қамтамасыз ететін қызметтер.
• Сангренель — Кафка кластерін жүктемені сынауға арналған құрал.
• Кафка метрикасын және инфрақұрылымын визуализациялауға арналған Grafana бақылау тақталары: Кубернетес Кафка, Түйін экспорттаушысы.
• Kubernetes жүйесінде Кафка кластерін орнатудың ең оңай жолы үшін Supertubes CLI. Zookeeper, Kafka операторы, Envoy және басқа да көптеген компоненттер Kubernetes жүйесінде өндіріске дайын Кафка кластерін іске қосу үшін орнатылған және дұрыс конфигурацияланған.
  • Орнату үшін супертүтіктер CLI берілген нұсқауларды пайдаланыңыз осында.

EKS кластері

Арнайы жұмысшы түйіндері бар EKS кластерін дайындаңыз c5.4x үлкен Кафка брокерлері бар қосқыштар үшін әртүрлі қолжетімділік аймақтарында, сондай-ақ жүктеме генераторы мен мониторинг инфрақұрылымына арналған арнайы түйіндер.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

EKS кластері іске қосылғаннан кейін оның біріктірілгенін қосыңыз мониторинг қызметі — ол Прометей мен Графаны кластерге орналастырады.

Кафка жүйесінің құрамдас бөліктері

CLI супертүтіктерін пайдаланып, EKS жүйесінде Кафка жүйесінің құрамдастарын (Zookeeper, kafka-operator) орнатыңыз:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Кафка кластері

Әдепкі бойынша, EKS түрі EBS томдарын пайдаланады gp2, сондықтан томдарға негізделген бөлек сақтау класын жасау керек io1 Кафка кластері үшін:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

Брокерлер үшін параметрді орнатыңыз min.insync.replicas=3 және үш түрлі қолжетімділік аймағындағы түйіндерге брокер қосқыштарын орналастырыңыз:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

Тақырыптар

Біз үш жүктеме генераторының данасын параллель орындадық. Олардың әрқайсысы өз тақырыбына жазады, яғни бізге барлығы үш тақырып қажет:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

Әрбір тақырып үшін репликация коэффициенті 3 - жоғары қолжетімді өндіріс жүйелері үшін ұсынылатын ең аз мән.

Жүктеме жасау құралы

Біз жүктеме генераторының үш данасын іске қостық (әрқайсысы бөлек тақырыпта жазды). Жүктеме генераторының түйіндері үшін олар тек олар үшін бөлінген түйіндерге жоспарланатындай түйіндердің ұқсастығын орнату керек:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

Назар аударатын бірнеше тармақ:

• Жүктеме генераторы ұзындығы 512 байт хабарламаларды жасайды және оларды Кафкаға 500 хабарламалар бумаларында жариялайды.
• Аргумент қолдану -required-acks=all Хабардың барлық синхрондалған көшірмелерін Кафка брокерлері қабылдаған және растаған кезде жарияланым сәтті деп саналады. Бұл эталонда біз көшбасшылардың хабарламаларды қабылдау жылдамдығын ғана емес, сонымен қатар олардың ізбасарларының хабарламаларды қайталау жылдамдығын да өлшегенімізді білдіреді. Бұл сынақтың мақсаты тұтынушының оқу жылдамдығын бағалау емес (тұтынушылар) Жақында алынған хабарламалар әлі де ОЖ бетінің кэшінде қалады және оны дискіде сақталған хабарламаларды оқу жылдамдығымен салыстыру.
• Жүктеме генераторы 20 жұмысшыны қатар жүргізеді (-workers=20). Әрбір жұмысшыда жұмысшының Кафка кластеріне қосылуын бөлісетін 5 өндіруші бар. Нәтижесінде әрбір генераторда 100 өндіруші бар және олардың барлығы Кафка кластеріне хабарламалар жібереді.

Кластердің денсаулығын бақылау

Кафка кластерін жүктеуді сынау кезінде біз сонымен қатар подкасттың қайта іске қосылуының, синхрондалмаған көшірмелердің және минималды ауытқулармен максималды өткізу қабілетінің болмауына көз жеткізу үшін оның күйін бақылап отырдық:

• Жүктеме генераторы жарияланған хабарлар саны мен қателік жылдамдығы туралы стандартты статистиканы жазады. Қате деңгейі бірдей болуы керек 0,00%.
• Круиздік бақылау, kafka-оператор арқылы орналастырылған, бақылау тақтасын қамтамасыз етеді, онда біз кластердің күйін де бақылай аламыз. Бұл панельді көру үшін:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR деңгейі («синхрондалған» көшірмелердің саны) жиырылуы мен кеңеюі 0-ге тең.

Өлшеу нәтижелері

3 брокер, хабарлама көлемі – 512 байт

Үш брокерге біркелкі бөлінген бөлімдер арқылы біз өнімділікке қол жеткізе алдық ~500 Мб/с (секундына шамамен 990 мың хабарлама):

JVM виртуалды машинасының жад тұтынуы 2 ГБ аспады:

Дискінің өткізу қабілеті брокерлер жұмыс істеп тұрған барлық үш данада енгізу/шығару түйінінің максималды өткізу қабілетіне жетті:

Түйіндер бойынша жадты пайдалану деректерінен жүйелік буферлеу және кэштеу ~10-15 ГБ орын алғаны шығады:

3 брокер, хабарлама көлемі – 100 байт

Хабарлама өлшемі азайған сайын өткізу қабілеті шамамен 15-20%-ға төмендейді: әрбір хабарламаны өңдеуге кеткен уақыт оған әсер етеді. Сонымен қатар, процессордың жүктемесі екі есеге жуық артты.

Брокер түйіндерінде әлі пайдаланылмаған ядролар болғандықтан, өнімділікті Кафка конфигурациясын өзгерту арқылы жақсартуға болады. Бұл оңай міндет емес, сондықтан өткізу қабілеттілігін арттыру үшін үлкенірек хабарлармен жұмыс істеген дұрыс.

4 брокер, хабарлама көлемі – 512 байт

Сіз жай ғана жаңа брокерлерді қосу және бөлімдердің тепе-теңдігін сақтау арқылы Кафка кластерінің өнімділігін оңай арттыра аласыз (бұл жүктеменің брокерлер арасында біркелкі бөлінуін қамтамасыз етеді). Біздің жағдайда, брокерді қосқаннан кейін кластердің өткізу қабілеті жоғарылады ~580 Мб/с (секундына ~1,1 миллион хабар). Өсу күтілгеннен аз болды: бұл негізінен бөлімдердің теңгерімсіздігімен түсіндіріледі (барлық брокерлер өз мүмкіндіктерінің шыңында жұмыс істемейді).

JVM құрылғысының жад тұтынуы 2 ГБ-тан төмен болды:

Дискілері бар брокерлердің жұмысына бөлімдердің теңгерімсіздігі әсер етті:

қорытындылар

Жоғарыда ұсынылған итерациялық тәсілді жүздеген тұтынушыларды қамтитын күрделі сценарийлерді қамту үшін кеңейтуге болады, қайта бөлу, жаңартуларды жылжыту, бөлімді қайта іске қосу және т.б. Мұның бәрі бізге әртүрлі жағдайларда Кафка кластерінің мүмкіндіктерінің шегін бағалауға, оның жұмысындағы кедергілерді анықтауға және олармен күресу жолдарын табуға мүмкіндік береді.

Біз Supertubes-ті кластерді жылдам және оңай орналастыру, оны конфигурациялау, брокерлер мен тақырыптарды қосу/жою, ескертулерге жауап беру және жалпы Кафканың Kubernetes-те дұрыс жұмыс істеуін қамтамасыз ету үшін әзірледік. Біздің мақсатымыз – басты тапсырмаға («Кафка хабарламаларын жасау» және «тұтыну») назар аударуға көмектесу және барлық ауыр жұмысты Supertubes және Кафка операторына тапсыру.

Егер сізді Banzai Cloud технологиялары мен Open Source жобалары қызықтырса, мына мекенжай бойынша компанияға жазылыңыз GitHub, LinkedIn немесе Twitter.

Аудармашыдан PS

Біздің блогта да оқыңыз:

• «K8s ішіндегі Redis операторымен бір оқиға және осы дерекқордағы деректерді талдауға арналған утилиталарға шағын шолу«;
• «RabbitMQ-ны Kubernetes-ке үздіксіз көшіру«;
• «CoreOS жүйесінен zetcd: ZooKeeper-ді...etcd жадымен ауыстыру«.

Ақпарат көзі: www.habr.com