Опыт трансформации контейнеризации проектов

Kubernetes
Опыт трансформации контейнеризации проектов

I. Обзор

1.1 Предыстория

В последнее время проект платформы миграции, разработанный совместно с моими коллегами, хочет пройти преобразование контейнеризации и следует общей тенденции к контейнеризации.Фронтальная платформа проекта разработана с Django, серверная часть Restful API дополнена высокопроизводительным интерфейсом. высокопроизводительная веб-инфраструктура Tornado, а агентская часть разработана с помощью Flask, каждая из которых использует преимущества нескольких крупных фреймворков Python.

Раньше тестовая среда CI/CD использовала Gitlab CI. После того, как мастер отправлял запрос на слияние, он автоматически собирался и развертывался. Официальная среда вручную вытягивала развертывание выпуска через конвейер Jenkins. Контейнерная трансформация размещала Jenkins в Kubernetes. Мастер принял запросы на работу и динамически генерировать ведомое устройство для выполнения задачи работы.

В этой статье описаны некоторые опыты, с которыми я столкнулся при преобразовании контейнеризации. Возможно, моих собственных исследований недостаточно. Ниже приводится мое личное понимание. Если вам это не нравится, не распыляйтесь. В процессе использования Kubernetes для контейнеризации проекта я решил использовать проект python.Это немного излишне, но благодаря этому преобразованию я понял множество функций контейнеризации, постоянно улучшал свои ИТ-технологии и обогатил свой стек навыков.

1.2 Преимущества преобразования контейнеризации

  • Более экономично: высокая эффективность использования ресурсов, максимальное извлечение и совместное использование физических ресурсов, несколько проектов могут лучше отразить многочисленные преимущества контейнеризации и сократить расходы на развертывание ИТ.
  • Быстрее: запуск за считанные секунды, что позволяет ускорить итерацию разработки, доставку и развертывание бизнес-систем.
  • Эластичность. Масштабирование эластичного контейнера и эластичное расширение могут выполняться в соответствии с бизнес-нагрузкой.
  • Удобство: Контейнерное бизнес-развертывание поддерживает сине-зеленые/серые/канареечные выпуски, откат и является более гибким и удобным.
  • Гибкость: отслеживайте состояние работоспособности узлов базовых узлов и гибко планируйте оптимальное развертывание узлов.
  • Строгая согласованность: контейнер упаковывает среду и код в образ, обеспечивая надежную согласованность между тестовой и рабочей средами.

1.3 Требования к трансформации контейнеризации

  • Разработчики знакомы с технологией виртуализации Docker и умеют писать Dockerfile.
  • Знаком с контейнерной системой оркестровки kubernetes и знаком с составлением списка ресурсов каждого компонента.
  • Разработчикам необходимо организовать структуру и написать код с учетом потребностей последующей оркестровки и развертывания контейнеров.
  • Разработчики должны знать значение каждого параметра в списке ресурсов kubernetes и контролировать всю архитектуру сверху донизу.
  • Рассмотрим высокую доступность архитектуры и стратегии безопасности RBAC, внедрение внешнего потока и телескопии после расширения.

II. Инструменты

2.1 Облачная экосистема

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

2.2 Применение инструмента

Некоторые инструменты и приложения, использованные при преобразовании этого проекта, будут доступны вам (позже будет время написать и поделиться каждым приложением инструмента отдельно)

  • хостинг кода

Сервер Gitlab для размещения кода и gitlab ci/cd, который позже можно будет разместить в кластере kubernetes.

  • Частный хостинг изображений

Используйте Harbour для хранения образов, управления аудитом и проверки образов, которые позже можно будет разместить в kubernetes.

  • Управление кластером

kubernetes-dashboard, веб-интерфейс удобен для просмотра и управления каждым компонентом, простое управление контейнерным терминалом, совместное использование и просмотр журналов.

Rancher, импортируйте приватизированную платформу kubernetes, чтобы упростить управление кластером, а также установку и развертывание приложений.

  • Управление хранилищем

Управление веб-интерфейсом распределенного кластера Ceph to mgr

Хранилище объектов minio/chartmuseum удобно для управления хранилищем диаграмм.

  • Интегрированная публикация

Jenkins выполняет непрерывную интеграцию, непрерывный выпуск и может быть размещен в кластере kubernetes позже.

  • мониторинг журнала

efk используется для мониторинга и управления журналами контейнеров кластера kubernetes, а f — инструмент для контейнерного мониторинга Flutend.

  • управление складом

kubeapps добавляет диаграмму и реестр для облегчения установки и развертывания helm.

  • Мониторинг приложений в контейнере

Prometheus + grafana, экспорт из каждого приложения и мониторинг из одного приложения в матрицу.

  • На следующем рисунке показана страница навигации, которая интуитивно отображает эти инструменты.

3. Требования к ремонту

3.1 Требования программы

3.1.1 Структура проекта

  • Создайте папку config для файла конфигурации отдельно, что удобно для kubernetes, чтобы позже создать configmap для сопоставления ресурсов.

​

img

  • Если на более позднем этапе оно развертывается как приложение без сохранения состояния развертывания, для общего хранилища данных следует создать отдельный каталог, чтобы его можно было подключить к тому позже.

​

img

  • Создайте отдельный каталог развертывания в каталоге результатов проекта для хранения

​

img

Например, подпроект разбит на Секрет создания configmap/deployment/service, который уже вытащил код из приватного репозитория.

  • В рамках проекта entrypoint.sh применим к записи контейнера и, наконец, добавитьexec "$@", что удобно для последующего добавления расширений конфигурации

​

img

3.1.2 Требования к коду

  • Конфигурационный файл максимально написан на языке yaml, что удобно для последующей загрузки в configmap для легкой модификации и чтения.

  • Из-за удобства мониторинга контейнеров на более позднем этапе Fluentd используется для совместной работы с EL для мониторинга кластера и приложений. в стандартный вывод, поэтому, если необходимо отслеживать журнал, его можно направить в стандартный вывод/стандартный вывод ошибок уже находится в файле журнала.

​

img

3.2 Требования к архитектуре

3.2.1 Основные ресурсы

  • рассчитать

Используйте облачные серверы для создания и развертывания кластеров kubernetes для предоставления вычислительных ресурсов и ресурсов памяти.

  • место хранения

Распределенная система хранения Ceph должна быть развернута с использованием дисков облачного сервера, чтобы предоставить базовые ресурсы хранения для kubernetes.

  • Интернет

Для передней секции требуется LB, который используется для проксирования приложения на NodePort, а сеть flannel используется внутри кластера kubernetes.

Перед тем, как узел к узлу обменивается данными через частную сеть vpc

    • Межконтейнерная связь: связь между несколькими контейнерами в одном POD с использованием сетевой карты lo.
    • Связь между POD: POD IP связывается напрямую с POD IP
    • POD и сервис: IP-адрес POD напрямую и IP-адрес кластера
    • Сервисная связь с внешними клиентами кластера, ingress, NodePort, Loadbacer

3.2.2 Введение в трафик

  • Его необходимо развернуть в общедоступном/частном режиме или на «голом железе», и это необходимо спланировать заранее.Облачный LB может использовать свой сертификат развертывания и загружать сертификат на семи уровнях.
  • Если нет облачного продукта, нужно рассмотреть вопрос о введении входящего трафика в кластер для загрузки сертификата.

4. Примеры частей проекта

4.1 Класс хранения

Используйте кластеры ceph для создания классов хранения и используйте CephFS для решения приложений, смонтированных между узлами.

  • Класс хранения ceph-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rdb
provisioner: ceph.com/rbd
reclaimPolicy: Retain
parameters:
  monitors: 10.xx.xx.xx:6789
  pool: kube
  adminId: admin
  adminSecretName: ceph-admin-secret
  adminSecretNamespace: kube-system
  userId: kube
  userSecretName: ceph-client-secret
  userSecretNamespace: kube-system
  fsType: xfs
  imageFormat: "2"
  imageFeatures: "layering"
  • аутентификация ceph ceph-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ceph-admin-secret
  namespace: kube-system
type: "kubernetes.io/rbd"
data:
  # ceph auth get-key client.admin |base64
  key: QVFCRitmUmM1c1FxxxxxxxxxxxxxxxxxxxxxxxxHFoQVh6NlRvQ2c9PQ==
  • для общих каталогов
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: go2cloud-api-pvc
  namespace: default
spec:
  storageClassName: "ceph-rdb"
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  • Файлы конфигурации монтируются через configmap
apiVersion: v1
data:
  config.yaml: |
    ---
    DB_ENGINE: mysql
    DB_HOST: mariadb-cluster-mariadb-master.default.svc.cluster.local
    DB_PORT: 3306
    DB_USER: go2clouduser
    DB_PASSWORD: go2xxxxxxxxx
    DB_NAME: go2cxxxxxxxx

    # Use Redis as cache
    # Redis配置,连接replication的master节点
    REDIS_HOST: redis-cluster-redis-ha-announce-0.default.svc.cluster.local
    REDIS_PORT: 6379
    REDIS_PASSWORD: go2cloxxxxxxxx
    # go2cloud-platform 监听端口
    HTTP_LISTEN_PORT: 8088
    # callback url
    API_MIGRATE_SERVER_URL: http://go2cloud-api-service.default.svc.cluster.local:8004
    PLATFORM_CALLBACK_URL: http://go2cloud-platform-service.default.svc.cluster.local:8088
kind: ConfigMap
metadata:
  name: go2cloud-platform-cm

4.2 Ресурсы, связанные с приложением

    • go2cloud-platform-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go2cloud-platform
  namespace: default
spec:
  selector:
    matchLabels:
      # 匹配下面选择的template 中的label.app名称
      app: go2cloud-platform
  replicas: 2
  template:
    metadata:
      labels: 
        app: go2cloud-platform
        release: latest
    spec: 
      imagePullSecrets:
      - name: registry-secret
      containers:
      - name: go2cloud-platform
        image: 10.234.xxx.xxx/go2cloud/go2cloud-plaxxxxx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8088
          protocol: TCP
        volumeMounts:
          # 必须匹配volumes的名称
        - name: go2cloud-platform-config
          mountPath: /data/config
          readOnly: true
        resources:
          requests:
            cpu: 250m
            memory: 520Mi
          limits:
            cpu: 500m
            memory: 1024Mi
        livenessProbe:
          tcpSocket: 
            port: 8088
          initialDelaySeconds: 20
      volumes:
      # 定义逻辑卷的名称
      - name: go2cloud-platform-config
        configMap:
          # 使用configmap资源的名称
          name: go2cloud-platform-cm
          items:
          # 使用configmap中到那个key
          - key: config.yaml
            # 使用configmap中到key映射到容器中到文件名称
            path: config.yaml
            mode: 0644
    • go2cloud-platform-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: go2cloud-platform-service
  namespace: default
spec:
  selector:
    app: go2cloud-platform
  type: NodePort
  ports:
  - name: http
    nodePort: 30020
    port: 8088
    targetPort: 8088
    protocol: TCP
    • registry-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: registry-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxMC4yMzQuMi4yMTgiOiB7CgkJCSJhdXRoIjogIllXNWphRzVsZERwWWVIcDRRRGM0T1E9PSIKCQl9Cgl9LAoJIkh0dHBIZWFkZXJzIjogewoJCSJVc2Vyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Dockerfile
FROM python:latest
LABEL maintainer="kaliarch"
ENV BASE_ROOT="/data" 
ADD . ${BASE_ROOT}
RUN pip install --default-timeout=100 -r ${BASE_ROOT}/requirements/requirements.txt \
&& ln -s ${BASE_ROOT}/entrypoint.sh /bin/entrypoint.sh


EXPOSE 8088/tcp
ENTRYPOINT ["/bin/sh","/bin/entrypoint.sh"]
CMD ["python","/data/runserver","start","all"]
    • entrypoint.sh
#!/bin/sh
# config go2cloud-api configfile


exec "$@"

5. Отражение

  • Лично я решил, что облачные технологии станут основным трендом на более позднем этапе, и заранее освоить технологию контейнерной оркестрации, чтобы стек технологий не устарел.
  • Гораздо быстрее будет в полной мере использовать облачные экологические приложения, чтобы адаптироваться к характеристикам собственных проектов для проведения трансформации контейнеризации.
  • Я чувствую, что облачные технологии — это главная тенденция в будущем, поэтому начните как можно скорее и используйте облачные технологии.
Категории