ks8データ管理--- PV / PVC

その他 2021-01-27 21:11:54 訪問数: null

1.背景

コンテナのいわゆるボリュームは、実際には、ホスト上のディレクトリをコンテナ内のディレクトリにバインドしてマウントすることです。ボリュームは、非常に優れたデータ永続性ソリューションを提供しますが、管理性にはまだ欠点があります。

  1. ボリュームを使用するには、ポッドはボリュームの出所を事前に知っている必要があり、事前に作成する必要があります。
  2. ポッドは通常、アプリケーション開発者によって維持されますが、ボリュームは通常、ストレージシステム管理者によって維持されます。開発者は上記の情報を入手する必要があります：管理者に尋ねるか、彼らが管理者です。

これは管理上の問題を引き起こします：アプリケーション開発者とシステム管理者の責任は一緒に結合されます。システム規模が小さい場合、または開発環境が許容できる場合。しかし、特に本番環境では、効率と安全性を考慮してクラスターサイズが大きくなると、これは解決しなければならない問題になります。

2、PV

1はじめに

PersistentVolume（PV）は、クラスター内の管理者によって構成されたネットワークストレージのセクションです。クラスター内のリソースは、ノードがクラスターリソースであるようなものです。PVはボリュームなどのボリュームプラグインですが、そのライフサイクルは、PVを使用する単一のポッドから独立しています。このAPIオブジェクトは、ストレージの実装の詳細、つまりNFS、iSCSI、またはクラウドプロバイダー固有のストレージシステムをキャプチャします。

PersistentVolumeClaim（PVC）は、ユーザーによるストレージの要求です。PersistentVolumeClaim（PVC）は、ポッドに似たPVの要求です。ポッドはノードリソースを消費し、PVCはPVリソースを消費します。ポッドは、特定のレベルのリソース（CPUとメモリ）を要求できます。ステートメントは、特定のサイズとアクセスモードを要求できます（たとえば、読み取り/書き込みを1回、または読み取り専用を複数回行うことができます）。

PVCとPVの間には1対1の対応があります。PersistentVolumeClaimを使用すると、ユーザーは必要なストレージリソースをKubernetesに伝えるだけでよく、実際のスペースがどこに割り当てられているか、アクセス方法などを気にする必要はありません。 -レベルの詳細。これらのストレージプロバイダーの基礎となる情報は管理者に渡され、管理者のみがPersistentVolumeの作成の詳細に注意を払う必要があります。

PersistentVolumeClaimsを使用すると、ユーザーは抽象ストレージリソースを使用できますが、PersistentVolumesは通常、問題ごとに異なる属性（パフォーマンスなど）を必要とします。クラスタ管理者は、サイズやアクセスモードだけでなく、さまざまなPersistentVolumeをさまざまな方法で提供できる必要があります。これらのボリュームがどのように実装されているかを、ユーザーに知らせる必要はありません。これらの要件には、StorageClassリソースがあります。

StorageClassは、管理者が提供するストレージの「クラス」を説明する方法を提供します。さまざまなクラスを、サービス品質レベル、バックアップ戦略、またはクラスター管理者が決定した任意の戦略にマッピングできます。Kubernetes自体は、カテゴリが何を表しているかを自明です。この概念は、他のストレージシステムでは「プロファイル」と呼ばれることもあります。

2）ライフサイクル

PVはクラスター内のリソースです。PVCはこれらのリソースの要求であり、リソースのチェックとしても機能します。PVとPVC間の相互作用は、次のライフサイクルに従います。
プロビジョニング->バインディング->使用->リリース->リサイクル

ステップ1：プロビジョニングプロビジョニング-クラスター外のストレージシステムまたはクラウドプラットフォームを介してストレージ永続性サポートを提供します。

  • 静态提供Static：集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费。
  • 动态提供Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。

ステップ2：バインディングバインディング-ユーザーはpvcを作成し、必要なリソースとアクセスモードを指定します。利用可能なPVが見つかるまで、PVCはバインドされないままになります。

ステップ3：使用方法-ユーザーはポッドのようなボリュームでpvcを使用できます。

ステップ4：リリースリリース-ユーザーはpvcを削除してストレージリソースを再利用すると、pvは「リリース済み」ステータスになります。

以前のデータは引き続き保持されるため、これらのデータはさまざまな戦略に従って処理する必要があります。そうしないと、これらのストレージリソースを他のPVCで使用できません。

ステップ5：リサイクル-pvは、保持、リサイクル、削除の3つのリサイクル戦略を設定できます。

  • 保留策略：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
  • 删除策略：当删除与之绑定的PVC时候。
  • 回收策略：这个在1.14版本中以及被废弃，取而代之的是推荐使用动态存储供给策略，它的功能是当删除与该PV关联的PVC时，自动删除该PV中的所有数据。

注：
1> PVは最初にPODで作成する必要があり、ネットワークストレージのみがどのノードにも属することはできません。HostPathタイプをサポートしていますが、PODがスケジュールされるノードがわからないため、HostPathタイプPVを定義する必要があります。 。すべてのノードにHostPathで指定されたパスが必要であることを確認します。
2>現在、NFSおよびHostPathタイプのボリュームのみがリサイクル戦略をサポートしており、AWS EBS、GCE PD、Azure Disk、Cinderは削除戦略をサポートしています。

3）PVサポートの種類

GCEPersistentDisk、NFS、CephFS、HostPath、Glusterfs等

4）PVボリュームステージステータス

使用可能：リソースは要求されていません。
バインド：ボリュームは要求にバインドされています。
解放：要求は削除され、ボリュームは解放された状態ですが、クラスターによって再利用されていません。
失敗：自動ボリューム回復に失敗しました

5）PVアクセスモデル

accessModes：3種類の
ReadWriteMany（RWX）マルチチャネル読み取りおよび書き込みをサポートします。ボリュームは、クラスター内の複数のノードによってマウントおよび読み取りと書き込みが可能です
。ReadWriteOnce（RWO）シングルチャネル読み取りおよび書き込み、ボリュームはマウントのみ可能です。そして読み取る単一のクラスタ・ノードによって。
ReadOnlyMany（ROX））マルチチャンネル読み取り専用ボリュームは、複数のクラスタ・ノードによって実装することができるのみ読み取ることができる。
3つのアクセスモデルは、ここであり、異なるストレージタイプは、異なるアクセス・モデルをサポート。具体的なサポートについては、公式Webサイトを確認してください。たとえば、ここでは3つすべてをサポートするnfsを使用します。ただし、ISCIはReadWriteManyをサポートしていません。HostPathはReadOnlyManyとReadWriteManyをサポートしていません。

3、PVC

1はじめに

PVCはユーザーレベルです。ストレージリソースの要求として、主にストレージスペースのサイズ、アクセスモード、PVの選択条件、ストレージカテゴリ、およびその他の情報の設定が含まれます。

2）PVCパラメーターの詳細な説明（PVC yamlテンプレート）

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: test-pvc1
spec: 
  accessModes: 
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs-stoarge
  selector:
  	matchLabels:
  	  pv: test-pv1

3）PVCパラメータの説明

spec.accessModes：アクセスモード;ストレージリソースへのユーザーアプリケーションのアクセス許可について説明します。

  • RWO：ReadWriteOnce、読み取りと書き込みのために単一のノードのみをマウントできます。
  • ROX：ReadOnlyMany、複数のノードをマウントして読み取り専用にすることができます。
  • RWX：ReadWriteMany。読み取りと書き込みのために複数のノードをマウントできます。

spec.resources.requests.storage：リソースリクエストのストレージサイズ
spec.storageClassName;：ストレージボリュームモード、StorageClassリソースオブジェクトの名前を指定します。特定のカテゴリのPVは、そのカテゴリをリクエストしたPVCにのみバインドできます;（動的ストレージ）;もちろん可能です。また、spec .storageClassName = ""に設定すると、特定のタイプを設定していないPVは、タイプを要求しないPVCとのみバインド（静的ストレージ）できます。
spec.selector.matchLabels：PV選択条件、PVバインディングは、ラベルマッチングを通じて実行できます。また、spec.selector.matchExpressions：条件ラベルの説明を通じて実行できます。

4）PVCのライフサイクル

PVCには、4つのライフサイクルステージもあります。使用可能/バインド済み/リリース済み/失敗
可能：使用可能状態、PVバインドなし、
バインド済み：バインド済み状態、すでにPV
にバインド済み、リリース済み：リリース済み状態、バインド済みPV削除済み、リソースはリリース済みですが、クラスターによって回復されません;
失敗：失敗状態、自動リソース回復に失敗しました;

5）PVCの一般的なコマンド

kubectl create -f pvc.yaml   # 创建（yaml的方式）
kubectl delete pvc pvc_name  # 删除
kubectl get pvc              # 查看所有PVC
kubectl get pvc pvc_name     # 查看某个PVC
kubectl describe pvc pvc_name # 查看详情

注：特定の名前空間にある場合、-nns_nameを上記のコマンドに追加できます

4. PVCおよびPV結合原理（pvおよびpvcのメカニズム）

1）pvおよびpvcバインディング要件

  1. PVのストレージサイズなど、PVとPVCのスペックフィールドは一致する必要があります
  2. PVとPVCのstorageClassNameフィールドは同じである必要があります
  3. PVは永続ストレージボリュームを記述します。このAPIオブジェクトは主に、NFSマウントディレクトリなど、ホストに永続的に格納されるディレクトリを定義します。PVCは、ある種の永続ストレージを提供する永続ストレージとして理解できます。ストレージの説明、ただし、特定の実装は提供しません
  4. 永続ストレージの実装部分はPVによって完了します
  5. PVとPVCのバインド、実際にはPVオブジェクトの名前は、
    PVとPVCポッドがYAMLファイルなどのボリュームの従来型hostPathとして正常にバインドできる場合、spec.volumeNamePVCオブジェクトのフィールドに入力します。

2）ストレージを共有する手順

ポッド（展開などはPVCで構成されます）-> PVC-> PV->ストレージリソース。

1>リソース供給

PVCが使用するストレージリソースは、静的にバインドすることも動的にバインドすることもできます。静的モードでは、集中管理者が対応するPVを事前に作成してストレージ特性を設定します。動的モードでは、集中管理者がStorageClassリソースを事前に作成して背面を記述します。 -endstorage。PVCストレージタイプは作成時に宣言されます。PVCが作成されると、k8sは適切なPVを自動的に作成し、それをPVCにバインドします。

2>リソースバインディング

PVCが作成された後、PVCは既存のPVから適切なPVを選択してバインドします（特定のバインドはラベルを介して行うことも、ラベルを介して行うこともできません。システムは自動的に適切なPV（容量などのパラメーター）を選択します。バインディングセット。）、バインディングは成功し、ステータスはバインドされ、PVは対応するPVCによって排他的にバインドされ、PVCが解放されない限り他のPVCによってバインドすることはできません。k8sシステムで適切なPVが見つからない場合、PVCは常に保留状態になります。

3>リソース使用量

Deploymentなどのリソースで、spec.template.spec.volumesを介してPVCマウントパスを設定します。

4>リソースリリース

PVCを削除すると、PVCにバインドされているPVのステータスが「リリース済み」になります。PVCのストレージデバイス上のデータを削除すると、対応するPVを他のPVCにバインドできます。

5>リソースのリサイクル

リサイクルポリシーは、spec.persistentVolumeReclaimPolicyを介してPVに設定できます。これは主に、バインドされたPVCが削除された後、リソースが解放された後、ストレージデバイス上のPVCによって書き込まれたデータを処理するために使用されます。

  • 保持：PVCを削除した後、PVはデータを保持します。
  • リサイクル：スペースをリサイクルし、PVCを削除した後にファイルをクリアするだけです;（NFSおよびHostPathストレージのサポート）;
  • 削除：PVCを削除した後、PVに接続されているバックエンドストレージがデータを削除します（AWS EBS、Azure Disk、Cinderボリューム、GCE PDサポート）。

5.ケースのデモンストレーション

1）nfsサービスをビルドします（node2 | node3 | node4がインストールされています）

yum -y install nfs-utils
mkdir -p /nfsdata
echo "/nfsdata *(rw,sync,no_root_squash)" > /etc/exports
systemctl start nfs-server && systemctl enable nfs-server
showmount -e

ここに画像の説明を挿入

2）pvを作成します（pvのyamlには、ラベルマーキング用のmetadata.labelsが必要です）

cat node2-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:         # PV建立不要加名称空间，因为PV属于集群级别的
  name: pv1       # PV名称
  labels:         # 这些labels可以不定义
    name: pv1
    storetype: nfs
spec:              # 这里的spec和volumes里面的一样
  storageClassName: normal
  accessModes:     # 设置访问模型
    - ReadWriteOnce
    - ReadWriteMany
    - ReadOnlyMany
  capacity:         # 设置存储空间大小
    storage: 3Gi
  persistentVolumeReclaimPolicy: Recycle  # 回收策略
  nfs:
    path: /nfsdata
    server: 10.10.0.110

cat node3-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:         # PV建立不要加名称空间，因为PV属于集群级别的
  name: pv2       # PV名称
  labels:         # 这些labels可以不定义
    name: pv2
    storetype: nfs
spec:              # 这里的spec和volumes里面的一样
  storageClassName: normal
  accessModes:     # 设置访问模型
    - ReadWriteOnce
    - ReadWriteMany
  capacity:         # 设置存储空间大小
    storage: 5Gi
  persistentVolumeReclaimPolicy: Recycle  # 回收策略
  nfs:
    path: /nfsdata
    server: 10.10.0.111

cat node4-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:         # PV建立不要加名称空间，因为PV属于集群级别的
  name: pv3       # PV名称
  labels:         # 这些labels可以不定义
    name: pv3
    storetype: nfs
spec:              # 这里的spec和volumes里面的一样
  storageClassName: normal
  accessModes:     # 设置访问模型
    - ReadWriteOnce
  capacity:         # 设置存储空间大小
    storage: 10Gi
  persistentVolumeReclaimPolicy: Recycle  # 回收策略
  nfs:
    path: /nfsdata
    server: 10.10.0.112

kubectl apply -f node2-pv.yaml
kubectl apply -f node3-pv.yaml
kubectl apply -f node4-pv.yaml

ここに画像の説明を挿入

3）pvcを作成してpvをバインドします（pvのyamlにはラベルマーキング用のmetadata.labelsが必要です）

ここに画像の説明を挿入
赤いボックスはオプションです（指定されたpvに一致する場合は、3.4のポッドで指定されているようにポッドで指定することもできます）

以下に示すように、それぞれ3つのPVCを作成します。

猫pvc-vol.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc01   # pvc的名字
  namespace: default
  labels: # 这些labels可以不定义
    name: pvc01
    storetype: nfs
    capacity: 3Gi
spec:
  storageClassName: normal
  accessModes:  # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
 1. ReadWriteMany
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 3Gi  # 定义要求有多大空间

猫pvc-vol2.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc02   # pvc的名字
  namespace: default
  labels: # 这些labels可以不定义
    name: pvc02
    storetype: nfs
    capacity: 1Gi
spec:
  storageClassName: normal
  accessModes:  # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
 2. ReadWriteMany
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 1Gi  # 定义要求有多大空间

猫pvc-vol3.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc03   # pvc的名字
  namespace: default
  labels: # 这些labels可以不定义
    name: pvc03
    storetype: nfs
    capacity: 6Gi
spec:
  storageClassName: normal
  accessModes:  # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
 3. ReadWriteOnce
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 6Gi  # 定义要求有多大空间

kubectl apply -f pvc-vol.yaml
kubectl apply -f pvc-vol2.yaml
kubectl apply -f pvc-vol3.yaml

ここに画像の説明を挿入
ここに画像の説明を挿入ここに画像の説明を挿入

4）ポッドにPVCを使用する

ステップ1：名前空間を作成する

猫のポッド-ns.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: pv

kubectl apply -f pvc-vol.yaml

ステップ2：pvを作成する

猫のポッド-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:         # PV建立不要加名称空间，因为PV属于集群级别的
  name: nginx-pv  # PV名称
  labels:         # 这些labels可以不定义
    name: nginx-pv
    storetype: nfs
spec:              # 这里的spec和volumes里面的一样
  storageClassName: normal
  accessModes:     # 设置访问模型
    - ReadWriteOnce
    - ReadWriteMany
  capacity:         # 设置存储空间大小
    storage: 5Gi
  persistentVolumeReclaimPolicy: Recycle  # 回收策略
  nfs:
    path: /nfsdata
    server: 10.10.0.111

kubectl apply -f pod-pv.yaml

ステップ3：pvcを作成する

猫のポッド-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc   # pvc的名字
  namespace: pv
  labels: # 这些labels可以不定义
    name: nginx-pvc
    storetype: nfs
    capacity: 5Gi
spec:
  storageClassName: normal
  accessModes:  # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
 4. ReadWriteOnce
  resources: # 定义资源要求PV满足这个PVC的要求才会被匹配到
    requests:
      storage: 5Gi  # 定义要求有多大空间

ここに画像の説明を挿入
nginx-pvcはnginx-pvを消費し、nginx-pvは111ノードの下のnfsであるため、111のnfsディレクトリにファイルを書き込み、nginxコンテナに入力して確認します。

cd /nfsdata/ && echo '13' > index.html  #111节点写入数据
kubectl exec -it my-nginx-pod -n pv /bin/bash #进入容器查看

ここに画像の説明を挿入

ステップ4：ポッドを作成する

cat pod-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
  namespace: pv
  labels:
    name: my-nginx-pod
spec:
  containers:
    - name: my-nginx
      image: www.my.com/web/nginx:v1
      volumeMounts:
      - mountPath: "/usr/share/nginx/html"
        name: nginx-pv
  volumes:
    - name: nginx-pv
      persistentVolumeClaim:
        claimName: nginx-pvc  #将/usr/share/nginx/html挂载到nginx-pvc

ポッドサービスは正常であり、nginxデータディレクトリによって使用されるnginx-pvcに対応するpvが見つかりkubectl get pvます。これにより、nginx-pvcによって消費される特定のpvと、このpvによって使用されるnfsストレージを確認できます。次に、対応するnfsで共有します。ディレクトリの下のnginixデータディレクトリを参照してください。

5）デプロイでpvcを使用します（4.2および4.3で作成されたpvおよびpvcを使用）

ステップ1：デプロイメントを作成する

cat pvc-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      appname: myapp-nginx
  template:
    metadata:
      name: myapp
      labels:
        appname: myapp-nginx
    spec:
      containers:
      - name: myapp
        image: www.my.com/web/nginx:v1
        ports:
        - name: http
          containerPort: 80
          protocol: TCP
        volumeMounts:
          - name: nginxdata
            mountPath : /usr/share/nginx/html
      volumes:
        - name: nginxdata
          persistentVolumeClaim:
            claimName: pvc02  #将/usr/share/nginx/html挂载到pvc02上

ここでは、ボリュームを使用して、使用するPVCを宣言できます。永続ボリュームを自分で定義するのと似ていることがわかりますが、ここでは、PVCの名前を直接使用する方が簡単です。コンテナ内の/ usr / share / nginx / htmlディレクトリを使用すると、NFSサーバー上のディレクトリにデータが書き込まれます。

ステップ2：svcを作成します

cat pvc-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy
spec:
  ports:
 5. port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    appname: myapp-nginx
  type: ClusterIP

kubectl  apply -f pvc-svc.yaml

pvc02が使用され、pvc02がpv1で消費されるため、ファイルはノード2のnfsサービスのディレクトリの下にあり、アクセステストで
ここに画像の説明を挿入
は、PVCがコンテナとPV間のインターフェイスと同等であることが示されています。ユーザーのみが対処する必要があります。 PVC付き。さらに、現在の環境でPVCにバインドされた適切なPVがない場合、作成したPODは失敗すると考えるかもしれません。これは確かに当てはまりますが、この問題を見つけた場合、適切なPVをすばやく作成すると、永続ストレージループコントローラーは引き続きPVCとPVをチェックし、適切なバインディングがあることが検出されると、自動的にバインドしてから一時停止したPODは、PODを再構築しなくても自動的に開始されます。

6）まとめ

PVCをPVにバインドするのは、永続ストレージボリューム制御ループです。このコントローラーもkube-manager-controllerの一部であり、マスター上で実行されます。ディレクトリのコンテナへの実際のマウントは、PODが配置されているホストで行われるため、kubeletを介して行われます。また、PVおよびPVCバインディングの作成は、PODが特定のノードにスケジュールされた後に実行されます。これらの操作が完了すると、PODを実行できます。PVを取り付けるプロセスを整理しましょう。

  1. ユーザーがPVCを含むPODを送信する
  2. スケジューラーは、node01などのさまざまなスケジューリングアルゴリズムに従って、PODをノードに割り当てます。
  3. Node01のkubeletは、VolumeManagerがストレージデバイスを準備するのを待ちます
  4. PVコントローラーはストレージプラグインを呼び出してPVを作成し、PVCとバインドします
  5. Attach / DetachControllerまたはVolumeManagerは、ストレージプラグインを介してデバイスの接続を実装します。（このステップはブロックデバイスストレージ用です）
  6. ボリュームマネージャーがストレージデバイスが利用可能になるのを待った後、デバイスを/ var / lib / kubelet / pods / <ポッドID> /volumes/kubernetes.io~ <ボリュームタイプ> / <ボリューム名>ディレクトリにマウントします
  7. Kubeletは、ボリュームの準備ができていることを通知され、PODを開始し、マッピングを通じてコン​​テナーにマウントします。

おすすめ

転載: blog.csdn.net/weixin_44729138/article/details/105864332
おすすめ
ランキング
パイソンのPythonの設計哲学--zen
VUE - 1を学習の開発ブログ
エントリートラバース地図要素
コードをHuaweiCloudgitリポジトリに同期する
Mavenは地元の倉庫とアリクラウド遠隔倉庫を設定しました
Linux は、ファイルとサブディレクトリの内容をすべてのユーザーが読み取り、書き込み、実行できるように変更します。
サンプルを作成するためのK8S展開＆サービス
ailoop2内部ailoop3内部の操作で、検討します。（コストは右である）海のデバッグ本当の巨人を使用した場合HearthBuddy愛2（第ヒーローのスキルが問題のトーテムを召喚使用していない、海の巨人を使用）、以下トーテムを召喚
お金が最も多くを得ました
[P1023]羅区税補助金（説明）
アーカイブ
もっと
2024-06-04(0)
2024-06-03(1)
2024-06-02(0)
2024-06-01(1)
2024-05-31(1)
2024-05-30(0)
2024-05-29(1)
2024-05-28(0)
2024-05-27(1)
2024-05-26(0)

コードワールド

© 2018 codetd.com