k 8 sのステータスサービスに対するデータ持続化
21768 ワード
前言
1、ステータスサービスと無ステータスサービスとは何ですか.
サーバ・プログラムにとって、ステータス・サービスがあるのか、それともステータス・サービスがないのかは、同じ開始者からの2つのリクエストがサーバ側でコンテキスト関係を備えているかどうかを判断する.ステータス化リクエストの場合、サーバ側は通常、リクエストに関する情報を保存し、各リクエストは以前のリクエスト情報をデフォルトで使用することができる.一方、無状態要求の場合、サーバ側が処理できるプロセスは、要求が携帯する情報、および他のサーバ側自身が保存し、すべての要求によって使用できる共通情報からすべて来なければならない.無状態のサーバープログラムで、最も有名なのはWEBサーバーです.毎回HTTPリクエストは以前とは関係なく、ターゲットURIを取得するだけです.目標の内容を得た後、今回の接続は殺され、何の痕跡もなかった.その後の発展の過程の中で、次第に無状態化の過程の中で、状態化の情報を加えて、例えばCOOKIE.サービス側はクライアントの要求に応答する時、クライアントにCOOKIEをプッシュして、このCOOKIEはサービス側の上のいくつかの情報を記録します.クライアントは後続の要求において、このCOOKIEを携帯することができ、サービス側はこのCOOKIEに基づいてこの要求のコンテキスト関係を判断することができる.COOKIEの存在は、無状態化から状態化への移行手段であり、外部拡張手段、COOKIEによってコンテキスト関係を維持する.ステータス化されたサーバには、MSN、ネットゲームなどのサーバなど、より広い応用範囲があります.彼は、各接続のステータス情報をサービス側で維持し、サービス側は、各接続の送信要求を受信すると、ローカルに格納された情報からコンテキスト関係を再現することができる.これにより、クライアントはデフォルトの情報を容易に使用でき、サービス側もステータス管理を容易に行うことができる.例えば、1人のユーザーがログインした後、サービス側はユーザー名に基づいて彼の誕生日などの以前の登録情報を取得することができる.また、後続の処理では、サービス側もこのユーザの履歴情報を容易に見つけることができる.ステータス・サーバは、機能実装においてより強力な利点がありますが、大量の情報とステータスを維持する必要があるため、パフォーマンスの面ではステータス・サーバなしにやや劣ります.無状態サーバは単純なサービスを処理する上で優位であるが、複雑な機能には多くの弊害がある.例えば、無状態サーバでインスタント通信サーバを実現することは、悪夢である.
2、K 8 sステータスサービスとステータスサービスなしのデータ持続化の違いは何ですか?
k 8 sでは,webのような無状態サービスに対してデータ持続化を実現する際には,私の前のブログ:K 8 sデータ持続化の自動PV作成方式で実現すればよい.しかし、データベースのようなステータスのあるサービスに対してこのようなデータ永続化方式を使用すると、データベースへの書き込み操作を行うと、バックエンドの複数のコンテナのうちの1つだけを書き込むことができるという深刻な問題があります.もちろん、nfsディレクトリの下にもデータベースに書き込まれたデータがありますが、サーバ_など、データベースに多くの影響要因があるため、他のデータベースに読み込めません.id、データベースパーティションテーブル情報など.
もちろん、データベースのほかにも、上記のデータ永続化方式を使用できないステータス・サービスがあります.
3、データ持続化の実現方式——StatefullSet
StatefulSetもリソースオブジェクト(kubelet 1.5バージョン以前はPetSetと呼ばれていた)であり、RS、RC、Deploymentと同様にPodコントローラである.
Kubernetesでは、ほとんどのPod管理は無状態、使い捨てのコンセプトに基づいています.たとえばReplication Controlでは、サービスを提供できるPodの数を簡単に保証します.Podが不健康と認定されると、Kubernetesは家畜に対する態度でこのPodを削除し、再建します.PetSet(ペットアプリケーション)は、家畜アプリケーションに比べて、状態のあるPodのセットで構成されており、各Podには独自の特殊で変更不可能なIDがあり、各Podには独自の削除できないデータがある.
無状態アプリケーションの管理に比べて,有状態アプリケーションの管理は非常に困難であることが知られている.ステータスのあるアプリケーションには固定IDが必要であり,自分の内部に見えない通信ロジックがあり,特にコンテナに激しい変動が生じるなどである.従来の意味では、ステータスアプリケーションの管理の一般的な考え方は、固定機器、静的IP、持続化ストレージなどである.KubernetesはPetSetという資源を利用して,状態Petと特定の物理施設との関連を弱める.1つのPetSetは、任意の時点で一定数のPetが実行され、各Petに独自のアイデンティティがあることを保証することができる.
「アイデンティティ」Petとは、Pet内のPodが次の特性を含むことを意味する.静的記憶; には固定ホスト名があり、DNSはアドレス可能である(Headless Serviceという特殊なサービスによって実現される安定したネットワークアイデンティティ.通常のサービスと比較して、HeadlessサービスにはCluster IPがなく、クラスタ内の各メンバーに一意のDNS名を提供し、クラスタ内のメンバー間の通信に使用される). 秩序あるindex(例えばPetSetの名前をmysqlと呼ぶと、最初に起動したPetをmysql-0、2番目をmysql-1と呼ぶ.このままでは、1つのPetがダウンすると、新しく作成したPetには元のPetと同じ名前が付与され、この名前で元のストレージにマッチし、ステータス保存が実現される.) 1、応用例:データベースアプリケーション、例えばMysql、PostgreSQLでは、固定ID(データ同期用)とNFS Volume(永続化ストレージ)が外部に接続されている必要があります. クラスタソフトウェア、例えばzookeeper、Etcdは、一定のメンバー関係を必要とする.2、使用制限 1.4新機能、1.3および以前のバージョンは使用できません. DNS、1.4あるいは1.4の後のDNSプラグインを使うことを要求して、1.4の前のプラグインはサービスの対応するIPを解析することしかできなくて、Pod(HostName)の対応するドメイン名を解析することができません; データ・ボリュームの永続化が必要(PVは、nfsのようなAPIを呼び出して記憶できないネットワークストレージの場合、データボリュームはPetSetを作成する前に静的に作成し、aws-ebs、vSphere、openstack CinderのようなAPI呼び出しで記憶を動的に作成できる仮想ストレージの場合、データボリュームは静的に作成できるほか、StorageClassで動的に作成することもできる.注が必要つまり、ダイナミックに作成されたPVは、デフォルトの回収ポリシーがdeleteであり、データを削除すると同時に、仮想ストレージボリュームを削除することもあります). 削除または縮小PetSetは、対応する永続化データボリュームを削除しません.これは、データセキュリティの考慮からです. は手動でPetSetをアップグレードするしかありません.
構成例
この方式は、K 8 sデータ持続化の自動PV作成方式と多くの共通点があり、下層NFSストレージ、rbacライセンスアカウントが必要であり、nfs-client-Provisionerはストレージを提供し、SCストレージ類はこれらのものを提供しているが、唯一の違いは、このようなステータスサービスのあるデータ持続化に対して、手動でPVを作成する必要はない.
registryプライベートウェアハウスの構築:
NFSサービスの構築:
以上はすべて準備作業に属します.
1、カスタムミラーを使用して、StatefulSetリソースオブジェクトを作成し、各データの永続化を要求する.コピー数は6個です.データ永続化ディレクトリ:/usr/local/apache 2/htdocs
rbacライセンスの作成
NFS-clinet-Provisionerの作成
SC(storageClass)の作成
POdの作成
2、完成後、0-5個目のPodを要求するメインディレクトリは、Version:--v 1サービスを拡張する.コピー数を10個に更新し、新しいPodのために持続的なPVを作成し続けるかどうかを検証する.PVC
1、ステータスサービスと無ステータスサービスとは何ですか.
サーバ・プログラムにとって、ステータス・サービスがあるのか、それともステータス・サービスがないのかは、同じ開始者からの2つのリクエストがサーバ側でコンテキスト関係を備えているかどうかを判断する.ステータス化リクエストの場合、サーバ側は通常、リクエストに関する情報を保存し、各リクエストは以前のリクエスト情報をデフォルトで使用することができる.一方、無状態要求の場合、サーバ側が処理できるプロセスは、要求が携帯する情報、および他のサーバ側自身が保存し、すべての要求によって使用できる共通情報からすべて来なければならない.無状態のサーバープログラムで、最も有名なのはWEBサーバーです.毎回HTTPリクエストは以前とは関係なく、ターゲットURIを取得するだけです.目標の内容を得た後、今回の接続は殺され、何の痕跡もなかった.その後の発展の過程の中で、次第に無状態化の過程の中で、状態化の情報を加えて、例えばCOOKIE.サービス側はクライアントの要求に応答する時、クライアントにCOOKIEをプッシュして、このCOOKIEはサービス側の上のいくつかの情報を記録します.クライアントは後続の要求において、このCOOKIEを携帯することができ、サービス側はこのCOOKIEに基づいてこの要求のコンテキスト関係を判断することができる.COOKIEの存在は、無状態化から状態化への移行手段であり、外部拡張手段、COOKIEによってコンテキスト関係を維持する.ステータス化されたサーバには、MSN、ネットゲームなどのサーバなど、より広い応用範囲があります.彼は、各接続のステータス情報をサービス側で維持し、サービス側は、各接続の送信要求を受信すると、ローカルに格納された情報からコンテキスト関係を再現することができる.これにより、クライアントはデフォルトの情報を容易に使用でき、サービス側もステータス管理を容易に行うことができる.例えば、1人のユーザーがログインした後、サービス側はユーザー名に基づいて彼の誕生日などの以前の登録情報を取得することができる.また、後続の処理では、サービス側もこのユーザの履歴情報を容易に見つけることができる.ステータス・サーバは、機能実装においてより強力な利点がありますが、大量の情報とステータスを維持する必要があるため、パフォーマンスの面ではステータス・サーバなしにやや劣ります.無状態サーバは単純なサービスを処理する上で優位であるが、複雑な機能には多くの弊害がある.例えば、無状態サーバでインスタント通信サーバを実現することは、悪夢である.
2、K 8 sステータスサービスとステータスサービスなしのデータ持続化の違いは何ですか?
k 8 sでは,webのような無状態サービスに対してデータ持続化を実現する際には,私の前のブログ:K 8 sデータ持続化の自動PV作成方式で実現すればよい.しかし、データベースのようなステータスのあるサービスに対してこのようなデータ永続化方式を使用すると、データベースへの書き込み操作を行うと、バックエンドの複数のコンテナのうちの1つだけを書き込むことができるという深刻な問題があります.もちろん、nfsディレクトリの下にもデータベースに書き込まれたデータがありますが、サーバ_など、データベースに多くの影響要因があるため、他のデータベースに読み込めません.id、データベースパーティションテーブル情報など.
もちろん、データベースのほかにも、上記のデータ永続化方式を使用できないステータス・サービスがあります.
3、データ持続化の実現方式——StatefullSet
StatefulSetもリソースオブジェクト(kubelet 1.5バージョン以前はPetSetと呼ばれていた)であり、RS、RC、Deploymentと同様にPodコントローラである.
Kubernetesでは、ほとんどのPod管理は無状態、使い捨てのコンセプトに基づいています.たとえばReplication Controlでは、サービスを提供できるPodの数を簡単に保証します.Podが不健康と認定されると、Kubernetesは家畜に対する態度でこのPodを削除し、再建します.PetSet(ペットアプリケーション)は、家畜アプリケーションに比べて、状態のあるPodのセットで構成されており、各Podには独自の特殊で変更不可能なIDがあり、各Podには独自の削除できないデータがある.
無状態アプリケーションの管理に比べて,有状態アプリケーションの管理は非常に困難であることが知られている.ステータスのあるアプリケーションには固定IDが必要であり,自分の内部に見えない通信ロジックがあり,特にコンテナに激しい変動が生じるなどである.従来の意味では、ステータスアプリケーションの管理の一般的な考え方は、固定機器、静的IP、持続化ストレージなどである.KubernetesはPetSetという資源を利用して,状態Petと特定の物理施設との関連を弱める.1つのPetSetは、任意の時点で一定数のPetが実行され、各Petに独自のアイデンティティがあることを保証することができる.
「アイデンティティ」Petとは、Pet内のPodが次の特性を含むことを意味する.
構成例
この方式は、K 8 sデータ持続化の自動PV作成方式と多くの共通点があり、下層NFSストレージ、rbacライセンスアカウントが必要であり、nfs-client-Provisionerはストレージを提供し、SCストレージ類はこれらのものを提供しているが、唯一の違いは、このようなステータスサービスのあるデータ持続化に対して、手動でPVを作成する必要はない.
registryプライベートウェアハウスの構築:
[root@master ~]# docker run -tid --name registry -p 5000:5000 -v /data/registry:/var/lib/registry --restart always registry
[root@master ~]# vim /usr/lib/systemd/system/docker.service # docker ，
ExecStart=/usr/bin/dockerd -H unix:// --insecure-registry 192.168.20.6:5000
[root@master ~]# scp /usr/lib/systemd/system/docker.service node01:/usr/lib/systemd/system/
[root@master ~]# scp /usr/lib/systemd/system/docker.service node02:/usr/lib/systemd/system/
[root@master ~]# systemctl daemon-reload
[root@master ~]# systemctl restart dockerNFSサービスの構築:
[root@master ~]# yum -y install nfs-utils
[root@master ~]# systemctl enable rpcbind
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start rpcbind
[root@master ~]# systemctl start nfs
[root@master ~]# showmount -e
Export list for master:
/nfsdata *以上はすべて準備作業に属します.
1、カスタムミラーを使用して、StatefulSetリソースオブジェクトを作成し、各データの永続化を要求する.コピー数は6個です.データ永続化ディレクトリ:/usr/local/apache 2/htdocs
rbacライセンスの作成
[root@master ljz]# vim rbac.yaml # yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-provisioner
namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-provisioner-runner
namespace: default
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["services", "endpoints"]
verbs: ["get","create","list", "watch","update"]
- apiGroups: ["extensions"]
resources: ["podsecuritypolicies"]
resourceNames: ["nfs-provisioner"]
verbs: ["use"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-provisioner
subjects:
- kind: ServiceAccount
name: nfs-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-provisioner-runner
apiGroup: rbac.authorization.k8s.io
[root@master ljz]# kubectl apply -f rbac.yaml # yaml
NFS-clinet-Provisionerの作成
[root@master ljz]# vim nfs-deploymnet.yaml # yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nfs-client-provisioner
namespace: default
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccount: nfs-provisioner
containers:
- name: nfs-client-provisioner
image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: ljz
- name: NFS_SERVER
value: 192.168.20.6
- name: NFS_PATH
value: /nfsdata
volumes:
- name: nfs-client-root
nfs:
server: 192.168.20.6
path: /nfsdata
[root@master ljz]# kubectl apply -f nfs-deploymnet.yaml # yaml SC(storageClass)の作成
[root@master ljz]# vim sc.yaml # yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: test-sc
provisioner: ljz
reclaimPolicy: Retain
[root@master ljz]# kubectl apply -f sc.yaml # yaml POdの作成
[root@master ljz]# vim statefulset.yaml # yaml
apiVersion: v1
kind: Service
metadata:
name: headless-svc
labels:
app: headless-svc
spec:
ports:
- name: testweb
port: 80
selector:
app: headless-pod
clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: statefulset
spec:
serviceName: headless-svc
replicas: 6
selector:
matchLabels:
app: headless-pod
template:
metadata:
labels:
app: headless-pod
spec:
containers:
- name: testhttpd
image: 192.168.20.6:5000/ljz:v1
ports:
- containerPort: 80
volumeMounts:
- name: test
mountPath: /usr/local/apache2/htdocs
volumeClaimTemplates:
- metadata:
name: test
annotations:
volume.beta.kubernetes.io/storage-class: test-sc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Mi
[root@master ljz]# kubectl apply -f statefulset.yaml
[root@master ljz]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-6649749f97-cl92m 1/1 Running 0 7m57s
statefulset-0 1/1 Running 0 26s
statefulset-1 1/1 Running 0 24s
statefulset-2 1/1 Running 0 20s
statefulset-3 1/1 Running 0 16s
statefulset-4 1/1 Running 0 13s
statefulset-5 1/1 Running 0 9s
[root@master ljz]# kubectl get pv,pvc2、完成後、0-5個目のPodを要求するメインディレクトリは、Version:--v 1サービスを拡張する.コピー数を10個に更新し、新しいPodのために持続的なPVを作成し続けるかどうかを検証する.PVC
[root@master ljz]# vim a.sh #
#!/bin/bash
for i in `ls /nfsdata`
do
echo "Version: --v1" > /nfsdata/${i}/index.html
done
[root@master ljz]# kubectl get pod -o wide # IP，
[root@master ljz]# curl 10.244.1.3
Version: --v1
[root@master ljz]# curl 10.244.1.5
Version: --v1
[root@master ljz]# curl 10.244.2.4
Version: --v1
#
[root@master ljz]# vim statefulset.yaml
apiVersion: v1
kind: Service
metadata:
name: headless-svc
labels:
app: headless-svc
spec:
ports:
- name: testweb
port: 80
selector:
app: headless-pod
clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: statefulset
spec:
updateStrategy:
rollingUpdate:
partition: 4
serviceName: headless-svc
replicas: 10
selector:
matchLabels:
app: headless-pod
template:
metadata:
labels:
app: headless-pod
spec:
containers:
- name: testhttpd
image: 192.168.20.6:5000/ljz:v2
ports:
- containerPort: 80
volumeMounts:
- name: test
mountPath: /usr/local/apache2/htdocs
volumeClaimTemplates:
- metadata:
name: test
annotations:
volume.beta.kubernetes.io/storage-class: test-sc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Mi
[root@master ljz]# kubectl get pod -w #
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-6649749f97-cl92m 1/1 Running 0 40m
statefulset-0 1/1 Running 0 33m
statefulset-1 1/1 Running 0 33m
statefulset-2 1/1 Running 0 33m
statefulset-3 1/1 Running 0 33m
statefulset-4 1/1 Running 0 33m
statefulset-5 1/1 Running 0 33m
statefulset-6 0/1 ImagePullBackOff 0 5m9s
statefulset-6 1/1 Running 0 5m41s
statefulset-7 0/1 Pending 0 0s
statefulset-7 0/1 Pending 0 0s
statefulset-7 0/1 Pending 0 2s
statefulset-7 0/1 ContainerCreating 0 2s
statefulset-7 1/1 Running 0 4s
statefulset-8 0/1 Pending 0 0s
statefulset-8 0/1 Pending 0 0s
statefulset-8 0/1 Pending 0 1s
statefulset-8 0/1 ContainerCreating 0 1s
statefulset-8 1/1 Running 0 3s
statefulset-9 0/1 Pending 0 0s
statefulset-9 0/1 Pending 0 0s
statefulset-9 0/1 Pending 0 1s
statefulset-9 0/1 ContainerCreating 0 1s
statefulset-9 1/1 Running 0 3s
statefulset-5 1/1 Terminating 0 33m
statefulset-5 0/1 Terminating 0 33m
statefulset-5 0/1 Terminating 0 33m
statefulset-5 0/1 Terminating 0 33m
statefulset-5 0/1 Pending 0 0s
statefulset-5 0/1 Pending 0 0s
statefulset-5 0/1 ContainerCreating 0 0s
statefulset-5 1/1 Running 0 1s
statefulset-4 1/1 Terminating 0 33m
statefulset-4 0/1 Terminating 0 34m
statefulset-4 0/1 Terminating 0 34m
statefulset-4 0/1 Terminating 0 34m
statefulset-4 0/1 Pending 0 0s
statefulset-4 0/1 Pending 0 0s
statefulset-4 0/1 ContainerCreating 0 0s
statefulset-4 1/1 Running 0 1s
[root@master ljz]# kubectl get pv,pvc # pv pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-161fc655-7601-4996-99c8-a13cabaa4ad1 100Mi RWO Delete Bound default/test-statefulset-0 test-sc 38m
persistentvolume/pvc-1d1b0cfd-83cc-4cd6-a380-f23b9eac0411 100Mi RWO Delete Bound default/test-statefulset-4 test-sc 37m
persistentvolume/pvc-297495a8-2117-4232-8e9a-61019c03f0d0 100Mi RWO Delete Bound default/test-statefulset-7 test-sc 3m41s
persistentvolume/pvc-2e48a292-cb30-488e-90a9-5184811b9eb8 100Mi RWO Delete Bound default/test-statefulset-5 test-sc 37m
persistentvolume/pvc-407e2c0e-209d-4b5a-a3fa-454787f617a7 100Mi RWO Delete Bound default/test-statefulset-2 test-sc 37m
persistentvolume/pvc-56ac09a0-e51d-42a9-843b-f0a3a0c60a08 100Mi RWO Delete Bound default/test-statefulset-9 test-sc 3m34s
persistentvolume/pvc-90a05d1b-f555-44df-9bb3-73284001dda3 100Mi RWO Delete Bound default/test-statefulset-3 test-sc 37m
persistentvolume/pvc-9e2fd35e-5151-4790-b248-6545815d8c06 100Mi RWO Delete Bound default/test-statefulset-8 test-sc 3m37s
persistentvolume/pvc-9f60aab0-4491-4422-9514-1a945151909d 100Mi RWO Delete Bound default/test-statefulset-6 test-sc 9m22s
persistentvolume/pvc-ab64f8b8-737e-49a5-ae5d-e3b33188ce39 100Mi RWO Delete Bound default/test-statefulset-1 test-sc 37m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/test-statefulset-0 Bound pvc-161fc655-7601-4996-99c8-a13cabaa4ad1 100Mi RWO test-sc 38m
persistentvolumeclaim/test-statefulset-1 Bound pvc-ab64f8b8-737e-49a5-ae5d-e3b33188ce39 100Mi RWO test-sc 37m
persistentvolumeclaim/test-statefulset-2 Bound pvc-407e2c0e-209d-4b5a-a3fa-454787f617a7 100Mi RWO test-sc 37m
persistentvolumeclaim/test-statefulset-3 Bound pvc-90a05d1b-f555-44df-9bb3-73284001dda3 100Mi RWO test-sc 37m
persistentvolumeclaim/test-statefulset-4 Bound pvc-1d1b0cfd-83cc-4cd6-a380-f23b9eac0411 100Mi RWO test-sc 37m
persistentvolumeclaim/test-statefulset-5 Bound pvc-2e48a292-cb30-488e-90a9-5184811b9eb8 100Mi RWO test-sc 37m
persistentvolumeclaim/test-statefulset-6 Bound pvc-9f60aab0-4491-4422-9514-1a945151909d 100Mi RWO test-sc 9m22s
persistentvolumeclaim/test-statefulset-7 Bound pvc-297495a8-2117-4232-8e9a-61019c03f0d0 100Mi RWO test-sc 3m41s
persistentvolumeclaim/test-statefulset-8 Bound pvc-9e2fd35e-5151-4790-b248-6545815d8c06 100Mi RWO test-sc 3m37s
persistentvolumeclaim/test-statefulset-9 Bound pvc-56ac09a0-e51d-42a9-843b-f0a3a0c60a08 100Mi RWO test-sc 3m34s
[root@master nfsdata]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-client-provisioner-6649749f97-cl92m 1/1 Running 0 54m 10.244.1.2 node01
statefulset-0 1/1 Running 0 47m 10.244.1.3 node01
statefulset-1 1/1 Running 0 47m 10.244.2.3 node02
statefulset-2 1/1 Running 0 47m 10.244.2.4 node02
statefulset-3 1/1 Running 0 47m 10.244.1.4 node01
statefulset-4 1/1 Running 0 12m 10.244.2.8 node02
statefulset-5 1/1 Running 0 13m 10.244.1.8 node01
statefulset-6 1/1 Running 0 18m 10.244.2.6 node02
statefulset-7 1/1 Running 0 13m 10.244.1.6 node01
statefulset-8 1/1 Running 0 13m 10.244.2.7 node02
statefulset-9 1/1 Running 0 13m 10.244.1.7 node01
#
[root@master nfsdata]# curl 10.244.2.6
Index of /
Index of /
[root@master nfsdata]# curl 10.244.1.8
Version: --v1
服务进行更新：在更新过程中，要求3以后的全部更新为Version：v2
[root@master ljz]# vim a.sh #
#!/bin/bash
for i in `ls /nfsdata/`
do
if [ `echo $i | awk -F - '{print $4}'` -gt 3 ]
then
echo "Version: --v2" > /nfsdata/${i}/index.html
fi
done
[root@master ljz]# sh a.sh #
[root@master ljz]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-client-provisioner-6649749f97-cl92m 1/1 Running 0 68m 10.244.1.2 node01
statefulset-0 1/1 Running 0 60m 10.244.1.3 node01
statefulset-1 1/1 Running 0 60m 10.244.2.3 node02
statefulset-2 1/1 Running 0 60m 10.244.2.4 node02
statefulset-3 1/1 Running 0 60m 10.244.1.4 node01
statefulset-4 1/1 Running 0 26m 10.244.2.8 node02
statefulset-5 1/1 Running 0 26m 10.244.1.8 node01
statefulset-6 1/1 Running 0 32m 10.244.2.6 node02
statefulset-7 1/1 Running 0 26m 10.244.1.6 node01
statefulset-8 1/1 Running 0 26m 10.244.2.7 node02
statefulset-9 1/1 Running 0 26m 10.244.1.7 node01
#
[root@master ljz]# curl 10.244.1.4
Version: --v1
[root@master ljz]# curl 10.244.2.8
Version: --v2