Блог

Я запускаю кластер GKE, в котором несколько модулей пытаются получить доступ к общему тому. Поскольку постоянные диски GC не разрешают доступ для чтения и записи, я настроил сервер NFS в кластере (таким же образом, как и во многих подобных примерах), чтобы разрешить это. Я использую как производственную, так и среду разработки в этом кластере в разных пространствах имен, но поскольку обе эти среды запускают одно и то же приложение, им обоим нужна своя файловая система.

В настоящее время решением этой проблемы является настройка 2 серверов NFS таким же образом (один для prod и один для dev). Похоже, что когда модули, которые монтируют том с помощью сервера NFS, находятся на том же узле, что и сам сервер NFS, они не могут монтировать (ошибка «Невозможно подключить или смонтировать тома […]: время ожидания ожидания условия истекло»). Однако, похоже, это происходит только для среды разработки, поскольку в среде prod не было никаких проблем. В настоящее время оба сервера NFS выделены одному и тому же узлу, что также может способствовать возникновению проблемы, но я не уверен.

Я пытался выяснить, есть ли проблема с наличием 2 серверов NFS таким образом, или есть какая-то проблема при попытке подключить модули к серверу NFS, работающему на том же узле, но пока безрезультатно. Есть идеи, что может вызвать проблему?

Журналы в модулях сервера nfs (одинаковые как для разработчиков, так и для prod):

 nfs-dev-server  Oct 30, 2020, 3:57:23 PM    NFS started 
nfs-dev-server  Oct 30, 2020, 3:57:22 PM    exportfs: / does not support NFS export 
nfs-dev-server  Oct 30, 2020, 3:57:22 PM    Starting rpcbind    
nfs-dev-server  Oct 30, 2020, 3:57:22 PM    rpcinfo: can't contact rpcbind: : RPC: Unable to receive; errno = Connection refused    
nfs-dev-server  Oct 30, 2020, 3:57:21 PM    Serving /   
nfs-dev-server  Oct 30, 2020, 3:57:21 PM    Serving /exports
  

Я воспроизвел вашу проблему, следуя руководству, на которое вы ссылались, и столкнулся с той же проблемой, и причиной этого было то, что я не изменил IP-адрес сервера при создании 2nd PersistentVolume

Вот как я развернул 2 сервера NFS в 2 отдельных пространствах имен в GKE- version: 1.17.12-gke.2502

Создайте 2 диска gcloud compute disks create --size=10GB --zone=us-east1-b gce-nfs-disk
gcloud compute disks create --size=10GB --zone=us-east1-b gce-nfs-disk2 , создайте развертывание и обслуживание NFS в dev пространстве имен

 apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-server
  namespace: dev
spec:
  replicas: 1
  selector:
    matchLabels:
      role: nfs-server
  template:
    metadata:
      labels:
        role: nfs-server
    spec:
      containers:
      - name: nfs-server
        image: gcr.io/google_containers/volume-nfs:0.8
        ports:
          - name: nfs
            containerPort: 2049
          - name: mountd
            containerPort: 20048
          - name: rpcbind
            containerPort: 111
        securityContext:
          privileged: true
        volumeMounts:
          - mountPath: /exports
            name: mypvc
      volumes:
        - name: mypvc
          gcePersistentDisk:
            pdName: gce-nfs-disk
            fsType: ext4
---
apiVersion: v1
kind: Service
metadata:
  name: nfs-server
  namespace: dev
spec:
  # clusterIP: 10.3.240.20
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
  selector:
    role: nfs-server
  

После успешного развертывания NFS создайте проверку ClusterIP службы kubectl get svc -n dev и добавьте ее в nfs: server: <CLUSTER_IP>

 apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: standard
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: <CLUSTER_IP_OF_SVC>
    path: "/"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs
  namespace: dev
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-nginx
  namespace: dev
spec:
  replicas: 6
  selector:
    matchLabels:
      name: nfs-nginx
  template:
    metadata:
      labels:
        name: nfs-nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: busybox
        volumeMounts:
          # name must match the volume name below
          - name: nfs
            mountPath: "/mnt"
      volumes:
      - name: nfs
        persistentVolumeClaim:
          claimName: nfs
  

Проверьте и подтвердите, что все запущено и работает:

 kubectl get pods -n dev -w
NAME                          READY   STATUS              RESTARTS   AGE
nfs-nginx-587f8bd757-4gm8z    1/1     Running             0          6s
nfs-nginx-587f8bd757-6lh4l    1/1     Running             0          6s
nfs-nginx-587f8bd757-czr4r    0/1     Running             0          6s
nfs-nginx-587f8bd757-m5vph    1/1     Running             0          6s
nfs-nginx-587f8bd757-wqcff    1/1     Running             0          6s
nfs-nginx-587f8bd757-xqnf9    1/1     Running             0          6s
nfs-server-5f58f8d764-gjjnf   1/1     Running             0          3m14s
  

Повторите то же самое для prod пространства имен, но не забудьте изменить IP-адрес nfs-service в prod пространстве имен и соответствующим образом изменить его в манифесте PV. После развертывания этого результат:

 $ kubectl get pods -n prod
NAME                           READY   STATUS    RESTARTS   AGE
nfs-nginx2-5d75567b95-7n7gk    1/1     Running   0          6m25s
nfs-nginx2-5d75567b95-gkqww    1/1     Running   0          6m25s
nfs-nginx2-5d75567b95-gt96p    1/1     Running   0          6m25s
nfs-nginx2-5d75567b95-hf9j7    1/1     Running   0          6m25s
nfs-nginx2-5d75567b95-k2jdv    1/1     Running   0          6m25s
nfs-nginx2-5d75567b95-q457q    1/1     Running   0          6m25s
nfs-server2-8654b89f48-bp9lv   1/1     Running   0          7m19s