Использование общих ресурсов Windows SMB из приложения развертывания Kubernetes

Мы переносим устаревшие приложения java и.net с локальных виртуальных машин на локальный кластер Kubernetes.

Многие из этих приложений используют файловые ресурсы Windows для передачи файлов из других существующих систем и обратно. Развертывание в Kubernetes имеет меньший приоритет, чем реорганизация всех решений, чтобы избежать использования общих ресурсов samba, поэтому, если мы хотим выполнить миграцию, нам нужно будет найти способ сохранить многие вещи такими, какие они есть.

Мы установили кластер с 3 узлами на машинах с 3 центами, используя Kubeadm и Canal.

Я не смог найти активно поддерживаемый плагин или библиотеку для монтирования SMB, кроме лазурных томов.

Я придумал, чтобы смонтировать общие ресурсы SMB на каждом узле centos, используя одинаковую точку монтирования на всех узлах, то есть: "/data/share1", затем я создал локальный PersistentVolume.

kind: PersistentVolume
apiVersion: v1
metadata:
  name: samba-share-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/data/share1"

и претензия,

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: samba-share-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

и присвоил претензию заявлению.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: samba-share-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: samba-share-deployment
        tier: backend
    spec:
      containers:
      - name: samba-share-deployment
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: samba-share-volume
      volumes:
      - name: samba-share-volume
        persistentVolumeClaim:
          claimName: samba-share-claim

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

Могу ли я сделать это по-другому? Может ли это быть нормально, если я отслеживаю точки монтирования и отключаю узел в kubernetes в случае сбоя монтирования?

Источник

2 ответа

Решение

Я задал тот же вопрос на r / kubernetes, и пользователь прокомментировал это. Мы пытаемся это сейчас, и, кажется, все в порядке.

https://www.reddit.com/r/kubernetes/comments/7wcwmt/accessing_windows_smbcifs_shares_from_pods/duzx0rs/

Нам пришлось столкнуться с подобной ситуацией, и я закончил тем, что разработал собственный драйвер Flexvolume для монтирования общих ресурсов CIFS в модули из примеров, которые я нашел в Интернете.

Я написал репо с решением, которое работает для моего варианта использования.

https://github.com/juliohm1978/kubernetes-cifs-volumedriver

Вам все еще нужно ввести cifs-utils и jq на каждом хосте Kubernetes в качестве предварительного условия. Но это позволяет вам создавать PersistentVoluems, которые монтируют тома CIFS и используют их в ваших модулях.

Я надеюсь, что это помогает.

Источник

В настоящее время я бы выбрал https://github.com/kubernetes-csi/csi-driver-smb . Это надежное решение, официальный проект Kubernetes и хорошо документированное.

Источник
Другие вопросы по тегам