Кубернетский кластер миграции - PullRequest
Новая
       6

Кубернетский кластер миграции

0 голосов
/ 02 июля 2018

В настоящее время у меня есть несколько учетных записей AWS, каждый со своим кластером Kubernetes. К сожалению, когда кластеры были первоначально развернуты с использованием kops, VPC были созданы с перекрывающимися блоками CIDR. Обычно это не было бы проблемой, поскольку каждый кластер существовал в своей собственной вселенной.

Вещи немного изменились, и теперь мы хотим реализовать пиринг VPC между счетами. Идея заключается в том, что пользователи, подключающиеся через VPN, имеют доступ ко всем ресурсам через указанный пиринг. Насколько я понимаю, перекрытие блоков CIDR станет серьезной проблемой при реализации пиринга.

Не похоже, что можно просто изменить блок CIDR существующего кластера. Является ли мой единственный вариант резервного копирования и восстановления кластера в новом VPC с чем-то вроде ark? Кто-нибудь прошел полную миграцию кластера? Мне было бы любопытно, если есть лучший ответ.

1 Ответ

0 голосов
/ 03 июля 2018

Ваше понимание верно: с копами вы не можете изменять блоки CIDR существующего кластера; он застрял в VPC, в котором он был создан, и вы не можете изменить блок CIDR VPC :

Диапазон IP-адресов VPC состоит из связанных блоков CIDR. с этим. Вы выбираете один блок CIDR при создании VPC, и вы можете добавить или удалить вторичные блоки CIDR позже. Блок CIDR, который вы добавить при создании VPC нельзя изменить , но вы можете добавить и удалить вторичные блоки CIDR, чтобы изменить диапазон IP-адресов VPC. (выделение мое)

Это подводит нас ко второму пункту: миграции вашего кластера. Это можно разбить на две фазы:

  1. Перенос инфраструктуры, управляемой kops
  2. Перенос рабочих нагрузок в кластере

1. Миграция инфраструктуры, управляемой kops

Вам потребуется перенести (т. Е. Заново создать) сам кластер kops: экземпляры ec2, объекты kops InstanceGroups и Cluster, различную инфраструктуру AWS и т. Д. Для этого вы можете использовать команду kops toolbox template: 

kops toolbox template --values /path/to/values.yaml --template /path/to/cluster/template.yaml > /path/to/output/cluster.yaml
kops create -f /path/to/output/cluster.yaml

Это инструмент, похожий на шлем, который позволяет вам шаблонизировать конфигурацию вашего кластера kops и передавать в различные файлы values.yaml. Возможно, вы захотите включить эту команду в небольшую оболочку сценария оболочки или Makefile, чтобы создать кластерные развертывания в один клик, чтобы легко и с повторением настроить инфраструктуру кластера k8s.

Пример файла кластера template.yaml и файла values.yaml может выглядеть следующим образом, включая спецификации для Cluster, а также master, worker и autoscale InstanceGroup s. 

# template.yaml
{{ $clusterSubdomain := (env "CLUSTER_SUBDOMAIN") }}
{{ $subnetCidr := (env "SUBNET_CIDR") }}

apiVersion: kops/v1alpha2
kind: Cluster
metadata:
  name: {{ $clusterSubdomain }}.k8s.example.io
spec:
  hooks:
  - manifest: |
      [Unit]
      Description=Create example user
      ConditionPathExists=!/home/example/.ssh/authorized_keys

      [Service]
      Type=oneshot
      ExecStart=/bin/sh -c 'useradd example && echo "{{ .examplePublicKey }}" > /home/example/.ssh/authorized_keys'
    name: useradd-example.service
    roles:
    - Node
    - Master
  - manifest: |
      Type=oneshot
      ExecStart=/usr/bin/coreos-cloudinit --from-file=/home/core/cloud-config.yaml
    name: reboot-window.service
    roles:
    - Node
    - Master
  kubeAPIServer:
    authorizationRbacSuperUser: admin
    featureGates:
      TaintBasedEvictions: "true"
  kubeControllerManager:
    featureGates:
      TaintBasedEvictions: "true"
    horizontalPodAutoscalerUseRestClients: false
  kubeScheduler:
    featureGates:
      TaintBasedEvictions: "true"
  kubelet:
    featureGates:
      TaintBasedEvictions: "true"
  fileAssets:
  - content: |
      yes
    name: docker-1.12
    path: /etc/coreos/docker-1.12
    roles:
    - Node
    - Master
  - content: |
      #cloud-config
      coreos:
        update:
          reboot-strategy: "etcd-lock"
        locksmith:
          window-start: {{ .locksmith.windowStart }}
          window-length: {{ .locksmith.windowLength }}
    name: cloud-config.yaml
    path: /home/core/cloud-config.yaml
    roles:
    - Node
    - Master
  api:
    dns: {}
  authorization:
    rbac: {}
  channel: stable
  cloudProvider: aws
  configBase: s3://my-bucket.example.io/{{ $clusterSubdomain }}.k8s.example.io
  etcdClusters:
  - etcdMembers:
    - instanceGroup: master-{{ .zone }}
      name: a
    name: main
  - etcdMembers:
    - instanceGroup: master-{{ .zone }}
      name: a
    name: events
  iam:
    allowContainerRegistry: true
    legacy: false
  kubernetesApiAccess:
  - {{ .apiAccessCidr }}
  kubernetesVersion: {{ .k8sVersion }}
  masterPublicName: api.{{ $clusterSubdomain }}.k8s.example.io
  networkCIDR: {{ .vpcCidr }}
  networkID: {{ .vpcId }}
  networking:
    canal: {}
  nonMasqueradeCIDR: 100.64.0.0/10
  sshAccess:
  - {{ .sshAccessCidr }}
  subnets:
  - cidr: {{ $subnetCidr }}
    name: {{ .zone }}
    type: Public
    zone: {{ .zone }}
  topology:
    dns:
      type: Public
    masters: public
    nodes: public
---
apiVersion: kops/v1alpha2
kind: InstanceGroup
metadata:
  labels:
    kops.k8s.io/cluster: {{ $clusterSubdomain }}.k8s.example.io
  name: master-{{ .zone }}
spec:
{{- if .additionalSecurityGroups }}
  additionalSecurityGroups:
{{- range .additionalSecurityGroups }}
  - {{ . }}
{{- end }}
{{- end }}
  image: {{ .image }}
  machineType: {{ .awsMachineTypeMaster }}
  maxSize: 1
  minSize: 1
  nodeLabels:
    kops.k8s.io/instancegroup: master-{{ .zone }}
  role: Master
  subnets:
  - {{ .zone }}
---
apiVersion: kops/v1alpha2
kind: InstanceGroup
metadata:
  labels:
    kops.k8s.io/cluster: {{ $clusterSubdomain }}.k8s.example.io
  name: nodes
spec:
{{- if .additionalSecurityGroups }}
  additionalSecurityGroups:
{{- range .additionalSecurityGroups }}
  - {{ . }}
{{- end }}
{{- end }}
  image: {{ .image }}
  machineType: {{ .awsMachineTypeNode }}
  maxSize: {{ .nodeCount }}
  minSize: {{ .nodeCount }}
  nodeLabels:
    kops.k8s.io/instancegroup: nodes
  role: Node
  subnets:
  - {{ .zone }}
---
apiVersion: kops/v1alpha2
kind: InstanceGroup
metadata:
  name: ag.{{ $clusterSubdomain }}.k8s.example.io
  labels:
    kops.k8s.io/cluster: {{ $clusterSubdomain }}.k8s.example.io
spec:
{{- if .additionalSecurityGroups }}
  additionalSecurityGroups:
{{- range .additionalSecurityGroups }}
  - {{ . }}
{{- end }}
{{- end }}
  image: {{ .image }}
  machineType: {{ .awsMachineTypeAg }}
  maxSize: 10
  minSize: 1
  nodeLabels:
    kops.k8s.io/instancegroup: ag.{{ $clusterSubdomain }}.k8s.example.io
  role: Node
  subnets:
  - {{ .zone }}

И файл values.yaml: 

# values.yaml:

region: us-west-2 
zone: us-west-2a  
environment: staging 
image: ami-abc123
awsMachineTypeNode: c5.large
awsMachineTypeMaster: m5.xlarge
awsMachineTypeAg: c5.large
nodeCount: "2"
k8sVersion: "1.9.3"
vpcId: vpc-abc123
vpcCidr: 172.23.0.0/16
apiAccessCidr: <e.g. office ip> 
sshAccessCidr: <e.g. office ip>
additionalSecurityGroups:
- sg-def234 # kubernetes-standard
- sg-abc123 # example scan engine targets
examplePublicKey: "ssh-rsa ..."
locksmith:
  windowStart: Mon 16:00 # 8am Monday PST
  windowLength: 4h

2. Миграция рабочих нагрузок в кластере

Не имея практического опыта работы с Ark, похоже, он хорошо подходит для вашего случая использования :

Миграция кластера

Использование резервных копий и восстановлений

Heptio Ark может помочь вам перенести ресурсы с одного кластера на другой, пока вы указываете каждый параметр Ark Config на один и тот же облачный объект место хранения. В этом сценарии мы также предполагаем, что ваши кластеры размещены на том же облачном провайдере. Обратите внимание, что Heptio Ark не поддержка миграции постоянных томов между облачными провайдерами. 

(Cluster 1) Assuming you haven’t already been checkpointing your data with the Ark schedule operation, you need to first back up your

весь кластер (замена по желанию): 

ark backup create <BACKUP-NAME>

The default TTL is 30 days (720 hours); you can use the --ttl flag to change this as necessary.

(Cluster 2) Make sure that the persistentVolumeProvider and backupStorageProvider fields in the Ark Config match the ones from

Кластер 1, так что ваш новый экземпляр сервера Ark указывает на такое же ведро. 

(Cluster 2) Make sure that the Ark Backup object has been created. Ark resources are synced with the backup files available in cloud

хранение. 

(Cluster 2) Once you have confirmed that the right Backup (<BACKUP-NAME>) is now present, you can restore everything with:

ark restore create --from-backup <BACKUP-NAME>

Настройка Ark на кластерах AWS кажется достаточно простой: https://github.com/heptio/ark/blob/master/docs/aws-config.md.

При первоначальной настройке со сценарием kops toolbox и конфигурацией Ark у вас должен быть чистый, повторяемый способ перенести кластер и превратить домашних животных в крупного рогатого скота, как мем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...