vfrans's questions

我正在努力设置 imagebuilder 以从 Amazon Linux 2 实例上的 S3 文件填充 authorized_keys 文件。

IAM 角色功能正常，管道运行良好（没有错误，也没有输出）

这是我正在使用的食谱

description: This is hello world testing document.
schemaVersion: 1.0
phases:
  - name: build
    steps:
      - name: Download_Authorized_Keys_File
        action: S3Download
        onFailure: Abort
        inputs:
          - source: 's3://mysuperbucket/authorized_keys'
            destination: '/home/ec2-user/.ssh/authorized_keys'
      - name: Ensure_Correct_File_Permission
        action: ExecuteBash
        onFailure: Abort
        inputs:
          commands:
            - 'chown ec2-user:ec2-user /home/ec2-user/.ssh/authorized_keys'
            - 'chmod 600 /home/ec2-user/.ssh/authorized_keys'

此外，在其他地方调查和复制该文件时，它运行良好并且文件存在。

当手动将该文件复制到目标时，它也可以工作。有没有人有任何线索？

在使用 kind ( https://kind.sigs.k8s.io/docs/user/quick-start )在 2 个工作节点 Kubernetes 集群上进行设置测试时，我想出了这个并且无法在其他地方找到信息。

我在 /var/testpv 中的所有工作节点上创建了一个文件夹，并创建了以下 PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pg-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: fast-disks
  local:
    path: /var/testpv
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - fvi-worker2
          - fvi-worker

它工作得很好，所以我创建了第二个：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pg-pv2
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: fast-disks
  local:
    path: /var/testpv
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - fvi-worker
          - fvi-worker2

（相同，只是名称不同）

然后我使用这个存储类创建了 2 个 PVC：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-disks

和

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim2
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-disks

然后，最后两个 pod 使用这些 PVC：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: example-local-claim

和

apiVersion: v1
kind: Pod
metadata:
  name: mypod2
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: example-local-claim2

一切正常，我可以看到在每个 pod 上创建的文件都进入了正确的存储，每个 pod 位于不同的工作节点上。

但是，如果我尝试创建一个新的 PV、PVC 和 pod，则没有任何错误！

更糟糕的是，PV 是在同一位置创建的，所以我实际上可以看到 pod1 或 pod2（取决于）文件！

我会假设 Kubernetes 会进行某种检查，以确保具有相同主机的 PV 是否确实存在，但显然事实并非如此。

我错过了什么吗？难道我做错了什么？或者在创建 PV 时是否真的需要非常小心？

感谢您的任何见解，