kubernetes-podのライフサイクル管理
7770 ワード
以下kubernetes 1.5.2バージョンに基づいて作成する
lifecycle
コンセプト
リソースオブジェクトを作成するときにlifecycleを使用して、コンテナの実行前と閉じる前のアクションを管理できます.
Lifecycleには2つのコールバック関数があります.
例1、配置コード
次の例では、PostStartおよびPreStopコールバック関数が設定されたJAVAを含むWebアプリケーションコンテナを定義します.コンテナの作成に成功したら、/sample.warを/appフォルダにコピーします.そして、コンテナが終了する前に、HTTP要求をhttp://monitor.com:8080/waringつまり、監視システムに警告を送信します.
具体例は次のとおりです.
例2、優雅にリソースオブジェクトを削除する
ユーザが、RC、deploymentなどのpodを含むリソースオブジェクトの削除を要求すると、K 8 Sは、アプリケーションが処理中の要求を完了した後、ソフトウェアを閉じるように、アプリケーションを優雅に閉じるために、2つの情報通知を提供する.
デフォルトでは、すべての削除操作の優雅な終了時間は30秒以内です.kubectl deleteコマンドは、--grace-period=のオプションをサポートし、ユーザーを実行してデフォルト値を変更します.0は削除が直ちに実行され、APIからpodが直ちに削除されるという新しいpodが同時に作成されることを示す.ノードには、すぐに終了するpodが設定されており、まだ短い優雅な終了時間帯を与えて、強制的に殺され始めます.
具体例は次のとおりです.
Init Container
コンセプト
K 8 SのPODには,システムコンテナ(POD Container)とユーザコンテナ(User Container)の2種類があり,ユーザコンテナでは現在,初期化コンテナ(Init Container)とアプリケーションコンテナ(App Container)の2種類に分類されている.
Init Containerは、初期化作業を行うコンテナです.1つ以上あってもよく、複数が定義された順序で順次実行される場合、すべての実行が完了した後にのみプライマリコンテナが起動します.1つのPodのストレージボリュームが共有されているため、Init Containerで生成されたデータはメインコンテナで使用できます.
Init Containerは、複数のK 8 SリソースでDeployment、DaemonSet、StatefulSet、Jobなどに使用できるが、いずれもPod起動時にメインコンテナ起動前に実行され、初期化作業を行う.
シーンの適用
他のモジュールReadyを待つ
例えばapacheを使用してwebサービスを導入するには、gitサーバからコードを引き出したり、実行環境が整っているかどうかを確認したりするなどの準備作業が必要です.Webサービスを実行しているPodでInit Containerを使用して、準備作業を実行し、完了したらInit Containerが終了して終了し、現在のapacheコンテナを起動することができます.
初期化の設定をする
たとえば,クラスタにすでに存在するすべてのメンバノードを検出し,プライマリコンテナがクラスタの構成情報を用意することで,プライマリコンテナが立ち上がった後にこの構成情報をクラスタに加えることができる.
例
アプリケーションの健康診断
K 8 Sのアプリケーション健康診断はlivenessProbeとreadinessProbeに分けられ、両者は似ているが、両者にはいくつかの違いがある.
livenessProbeは、サービス実行中にアプリケーションが正常に動作しているかどうかを確認し、正常でない場合はプロセスを殺します.一方、readness Probeは、アプリケーションの起動が完了した後、外部にサービスを提供する準備ができているかどうかを検出し、正常に検出を継続し、成功に戻るまで検出を継続します.
livenessProbe
多くのアプリケーションは長時間の実行を経て、最終的に実行できない状態に移行し、再起動を除いてリカバリできません.通常、K 8 Sはアプリケーションが終了したことを発見し、アプリケーション/podを再起動します.
アプリケーションが何らかの理由(バックエンドサービス障害など)で一時的に外部にサービスを提供できない場合がありますが、アプリケーションが終了していないため、K 8 Sは障害のあるpodを分離できず、呼び出し元が障害のあるpodにアクセスし、ビジネスが不安定になる可能性があります.K 8 SはlivenessProbeを提供し、アプリケーションが正常に動作しているかどうかを検出し、対応する状況に対して対応する救済措置を行う.
readinessProbe
readinessProbeが構成されていないリソースオブジェクトでは、podのコンテナの起動が完了すると、podのアプリケーションはサービスを外部に提供することができ、そのpodは対応するサービスを追加し、サービスを外部に提供することができると考えられます.しかし、一部のアプリケーションが起動すると、外部にサービスを提供するのに時間がかかる場合があります.この場合、外部にサービスを提供すると、実行結果は予想される効果を達成できず、体験に影響を与えます.
たとえばtomcatを使用するアプリケーションでは、簡単にtomcatの起動に成功すれば対外的にサービスを提供できるわけではありません.springコンテナの初期化、データベース接続などを待つ必要があります.スプリングbootアプリケーションの場合、デフォルトのactuatorには/healthインタフェースがあり、起動成功の判断に使用できます.
けんしゅつモード
exec-コマンド
ユーザコンテナ内でコマンドを1回実行し、コマンド実行の終了コードが0の場合、アプリケーションは正常に動作し、他のタスクアプリケーションは正常に動作しないと判断します.
TCPSocketAction
ユーザーコンテナのSocket接続(IPアドレス:ポート)を開こうとします.この接続を確立できる場合は、アプリケーションが正常に動作しているとみなされます.そうでない場合は、アプリケーションが正常に動作していないとみなされます.
HTTPGetAcction
コンテナ内のWebアプリケーションのweb hookを呼び出し、返されたHTTPステータスコードが200と399の間であれば、アプリケーションが正常に動作しているとみなし、そうでなければアプリケーションが正常に動作していないとみなします.HTTP健康診断を行うたびに指定されたURLにアクセスします.…httpGet:#httpgetで健康診断を行い、200-399の間に戻ると、コンテナ正常path:/#URIアドレスport:80#ポート番号#host:127.0.0.1#ホストアドレスscheme:HTTP#でサポートされているプロトコル、httpまたはhttps httpHeaders:''#カスタムリクエストのheader…
例
パラメータの説明initialDelaySeconds:コンテナの起動後にプローブを最初に実行するには、何秒待つ必要がありますか.periodSeconds:プローブを実行する頻度.デフォルトは10秒、最小1秒です.timeoutSeconds:プローブタイムアウト時間.デフォルトは1秒、最小は1秒です.successThreshold:プローブが失敗した後、少なくとも連続プローブが何回成功してから成功と認定されます.デフォルトは1です.livenessの場合は1でなければなりません.最小値は1です.failureThreshold:プローブが成功した後、少なくとも連続プローブが何回失敗してから失敗と認定されます.デフォルトは3です.最小値は1です.
転載先:https://www.cnblogs.com/lykops/p/8263115.html
lifecycle
コンセプト
リソースオブジェクトを作成するときにlifecycleを使用して、コンテナの実行前と閉じる前のアクションを管理できます.
Lifecycleには2つのコールバック関数があります.
PostStart： ， ， 、 。
PreStop： ， 、 。
例1、配置コード
次の例では、PostStartおよびPreStopコールバック関数が設定されたJAVAを含むWebアプリケーションコンテナを定義します.コンテナの作成に成功したら、/sample.warを/appフォルダにコピーします.そして、コンテナが終了する前に、HTTP要求をhttp://monitor.com:8080/waringつまり、監視システムに警告を送信します.
具体例は次のとおりです.
......
containers:
- image: sample:v2
name: war
lifecycle：
postStart:
exec:
command:
- “cp”
- “/sample.war”
- “/app”
prestop:
httpGet:
host: monitor.com
psth: /waring
port: 8080
scheme: HTTP
......
例2、優雅にリソースオブジェクトを削除する
ユーザが、RC、deploymentなどのpodを含むリソースオブジェクトの削除を要求すると、K 8 Sは、アプリケーションが処理中の要求を完了した後、ソフトウェアを閉じるように、アプリケーションを優雅に閉じるために、2つの情報通知を提供する.
1）、 ：K8S node docker stop ，docker PID 1 SIGTERM， ， ， （30s）， SIGKILL kill 。
2）、 pod （ PreStop ）， 。
デフォルトでは、すべての削除操作の優雅な終了時間は30秒以内です.kubectl deleteコマンドは、--grace-period=のオプションをサポートし、ユーザーを実行してデフォルト値を変更します.0は削除が直ちに実行され、APIからpodが直ちに削除されるという新しいpodが同時に作成されることを示す.ノードには、すぐに終了するpodが設定されており、まだ短い優雅な終了時間帯を与えて、強制的に殺され始めます.
具体例は次のとおりです.
kind: Deployment
metadata:
name: nginx-demo
labels:
app: nginx-demo
spec:
replicas: 1
template:
metadata:
labels:
app: nginx-demo
spec:
containers:
- name: nginx-demo
image: centos:nginx
lifecycle:
preStop:
exec:
# nginx -s quit gracefully terminate while SIGTERM triggers a quick exit
command: ["/usr/local/nginx/sbin/nginx","-s","quit"]
ports:
- name: http
containerPort: 80
Init Container
コンセプト
K 8 SのPODには,システムコンテナ(POD Container)とユーザコンテナ(User Container)の2種類があり,ユーザコンテナでは現在,初期化コンテナ(Init Container)とアプリケーションコンテナ(App Container)の2種類に分類されている.
Init Containerは、初期化作業を行うコンテナです.1つ以上あってもよく、複数が定義された順序で順次実行される場合、すべての実行が完了した後にのみプライマリコンテナが起動します.1つのPodのストレージボリュームが共有されているため、Init Containerで生成されたデータはメインコンテナで使用できます.
Init Containerは、複数のK 8 SリソースでDeployment、DaemonSet、StatefulSet、Jobなどに使用できるが、いずれもPod起動時にメインコンテナ起動前に実行され、初期化作業を行う.
シーンの適用
他のモジュールReadyを待つ
例えばapacheを使用してwebサービスを導入するには、gitサーバからコードを引き出したり、実行環境が整っているかどうかを確認したりするなどの準備作業が必要です.Webサービスを実行しているPodでInit Containerを使用して、準備作業を実行し、完了したらInit Containerが終了して終了し、現在のapacheコンテナを起動することができます.
初期化の設定をする
たとえば,クラスタにすでに存在するすべてのメンバノードを検出し,プライマリコンテナがクラスタの構成情報を用意することで,プライマリコンテナが立ち上がった後にこの構成情報をクラスタに加えることができる.
例
cat << EOF > lykops-deploy-init-container.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: lykops-deploy-init-container
labels:
project: lykops
app: init-container
version: v1
annotations:
pod.beta.K8S.io/init-containers:
- name: apache-web,
image: web:apache,
command: ["sh", "httpd -t"]
spec:
replicas: 1
minReadySeconds: 30
selector:
matchLabels:
name: lykops-deploy-init-container
project: lykops
app: init-container
version: v1
template:
metadata:
labels:
name: lykops-deploy-init-container
project: lykops
app: init-container
version: v1
spec:
containers:
- name: webapache
image: web:apache
command: [ "sh", "/etc/run.sh" ]
ports:
- containerPort: 80
name: http
protocol: TCP
EOF
kubectl create -f lykops-deploy-init-container.yaml
アプリケーションの健康診断
K 8 Sのアプリケーション健康診断はlivenessProbeとreadinessProbeに分けられ、両者は似ているが、両者にはいくつかの違いがある.
livenessProbeは、サービス実行中にアプリケーションが正常に動作しているかどうかを確認し、正常でない場合はプロセスを殺します.一方、readness Probeは、アプリケーションの起動が完了した後、外部にサービスを提供する準備ができているかどうかを検出し、正常に検出を継続し、成功に戻るまで検出を継続します.
livenessProbe
多くのアプリケーションは長時間の実行を経て、最終的に実行できない状態に移行し、再起動を除いてリカバリできません.通常、K 8 Sはアプリケーションが終了したことを発見し、アプリケーション/podを再起動します.
アプリケーションが何らかの理由(バックエンドサービス障害など)で一時的に外部にサービスを提供できない場合がありますが、アプリケーションが終了していないため、K 8 Sは障害のあるpodを分離できず、呼び出し元が障害のあるpodにアクセスし、ビジネスが不安定になる可能性があります.K 8 SはlivenessProbeを提供し、アプリケーションが正常に動作しているかどうかを検出し、対応する状況に対して対応する救済措置を行う.
readinessProbe
readinessProbeが構成されていないリソースオブジェクトでは、podのコンテナの起動が完了すると、podのアプリケーションはサービスを外部に提供することができ、そのpodは対応するサービスを追加し、サービスを外部に提供することができると考えられます.しかし、一部のアプリケーションが起動すると、外部にサービスを提供するのに時間がかかる場合があります.この場合、外部にサービスを提供すると、実行結果は予想される効果を達成できず、体験に影響を与えます.
たとえばtomcatを使用するアプリケーションでは、簡単にtomcatの起動に成功すれば対外的にサービスを提供できるわけではありません.springコンテナの初期化、データベース接続などを待つ必要があります.スプリングbootアプリケーションの場合、デフォルトのactuatorには/healthインタフェースがあり、起動成功の判断に使用できます.
けんしゅつモード
exec-コマンド
ユーザコンテナ内でコマンドを1回実行し、コマンド実行の終了コードが0の場合、アプリケーションは正常に動作し、他のタスクアプリケーションは正常に動作しないと判断します.
……
livenessProbe:
exec:
command:
- cat
- /home/laizy/test/hostpath/healthy
……
TCPSocketAction
ユーザーコンテナのSocket接続(IPアドレス:ポート)を開こうとします.この接続を確立できる場合は、アプリケーションが正常に動作しているとみなされます.そうでない場合は、アプリケーションが正常に動作していないとみなされます.
……
livenessProbe:
tcpSocket:
port: 8080
……
HTTPGetAcction
コンテナ内のWebアプリケーションのweb hookを呼び出し、返されたHTTPステータスコードが200と399の間であれば、アプリケーションが正常に動作しているとみなし、そうでなければアプリケーションが正常に動作していないとみなします.HTTP健康診断を行うたびに指定されたURLにアクセスします.…httpGet:#httpgetで健康診断を行い、200-399の間に戻ると、コンテナ正常path:/#URIアドレスport:80#ポート番号#host:127.0.0.1#ホストアドレスscheme:HTTP#でサポートされているプロトコル、httpまたはhttps httpHeaders:''#カスタムリクエストのheader…
例
cat << EOF > inessprobe.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: inessprobe
labels:
project: lykops
app: inessprobe
version: v1
spec:
replicas: 6
selector:
project: lykops
app: inessprobe
version: v1
name: inessprobe
template:
metadata:
labels:
project: lykops
app: inessprobe
version: v1
name: inessprobe
spec:
restartPolicy: Always
containers:
- name: inessprobe
image: web:apache
imagePullPolicy: Never
command: ['sh',"/etc/run.sh" ]
ports:
- containerPort: 80
name: httpd
protocol: TCP
readinessProbe:
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 120
periodSeconds: 15
timeoutSeconds: 5
livenessProbe:
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 180
timeoutSeconds: 5
periodSeconds: 15
EOF
cat << EOF > inessprobe-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: inessprobe
labels:
project: lykops
app: inessprobe
version: v1
spec:
selector:
project: lykops
app: inessprobe
version: v1
ports:
- name: http
port: 80
protocol: TCP
EOF
kubectl create -f inessprobe-svc.yaml
kubectl create -f inessprobe.yaml
パラメータの説明initialDelaySeconds:コンテナの起動後にプローブを最初に実行するには、何秒待つ必要がありますか.periodSeconds:プローブを実行する頻度.デフォルトは10秒、最小1秒です.timeoutSeconds:プローブタイムアウト時間.デフォルトは1秒、最小は1秒です.successThreshold:プローブが失敗した後、少なくとも連続プローブが何回成功してから成功と認定されます.デフォルトは1です.livenessの場合は1でなければなりません.最小値は1です.failureThreshold:プローブが成功した後、少なくとも連続プローブが何回失敗してから失敗と認定されます.デフォルトは3です.最小値は1です.
転載先:https://www.cnblogs.com/lykops/p/8263115.html