ポッド内K8S資源オブジェクト（名前空間、調達方針、再起動ポリシー、ヘルスチェック）

Aは、リソースオブジェクトをK8S

展開、サービス、ポッドは、3つのリソースオブジェクトのコアK8Sです

展開：コントローラ最も一般的なステートレスアプリケーション、サポートアプリケーションのスケーラブルな容量、ローリングアップグレードおよびその他の操作。

サービス：固定アクセスインタフェースの変更を提供し、弾性ポッドオブジェクトのライフサイクルは、サービスの発見やサービスへのアクセスのためにそこにあります。

ポッドは：容器のスケジューリングおよび操作の最小単位です。同じポッドは、USERに加えて、MOUNTをPIDをネットを共有する複数のコンテナ、UTS、IPCを実行することができます。

ReplicationControllerは：ポッドの各コピーは、任意の時点で目標の数を満たすことができることを保証するために、簡単な言葉で、それは各コンテナやコンテナのグループは常に実行されていて、アクセス可能です：古い世代ステートレスポッドのアプリケーションコントローラ。

RwplicatSet：ステートレスポッドコントローラー・アプリケーションの新世代は、異なるRCはタグセレクタサポートは、サポートのみ等価RCセレクタ（キーと値のペア）は、RSは、さらにセレクタのセットをサポートしていることが異なります。

StatefulSet：永続的なアプリケーションの状態管理は、それが各ポッドの一意の永続的な識別子を作成し、各ポッドの間の順序を保証するために、その中に配置から異なるデータベースサービスプログラムとして、存在するためセックス。

DaemonSet：ノードが除去されたときに、新しいノードは、例えばAポッドに追加されるように、このポッドはリサイクルされ、各ノードは、ポッドのコピーを実行することを保証します。

求人：アプリケーションは、このような宿題のタスクを処理するバッチとして、運用管理の完了後に終了することができます。

1.Podのライフサイクルは、次の段階として定義されています。

• 保留中：ポッドは、コンテナの画像を作成したが、まだポッドスケジューリング段階を含む、1つ以上の容器を、作成されていない、と、ダウンロードプロセスされています。
• 実行：ポッドは、ノードにスケジュールされているすべてのコンテナが作成されており、少なくとも1つのレセプタクルは、実行中または再起動されます。
• 成功：すべてのコンテナの通常の出口のポッド。
• 失敗しました：ポッドは、すべてのコンテナ出口に、少なくとも一つのコンテナが撤退であります。

2.特長

ポッドは、作成されるスケジューリングおよび管理の最小単位であり、
それぞれが別々のポッドIPを有し、
ポッド容器は、一つ以上の、共有メモリ等の共有名前空間で構成され、ポッド同じノード内のすべてのコンテナを;
容器ライフサイクル管理、
リソース使用制限、リソース（リクエスト、限界）;
コンテナは、プローブ：livenessProbeは、
一般に、レイヤ2ネットワークによって達成されるクラスタ内のポッドの間の任意のアクセスであってもよいです。

3.Podコンテナ

ドッカーでは、容器は、欠失は、検索対象が血管である変更、最小処理単位であり、容器は仮想化技術である、容器との間の分離は、分離は、Linuxの名前空間に基づいて達成されます。
K8Sにおいて、ポッドは、1つまたは複数の関連する容器と、ポッド容器延びる延長とみなすことができる、ポッドはセパレータであり、ポッド内部容器の群を含むこと（PID、ネットワークを含む共有されています、IPC、UTS）。また、コンテナ内のポッドは、共有ファイルシステムを実現するために、共有データボリュームにアクセスすることができます。

4.リソース要求および制限

ポッドを作成する場合、コンピューティングリソースは、（現在サポートされているリソースタイプのCPUおよびメモリ）、即ち、各コンテナ指定されたリソース要求（リクエスト）、およびリソース制限（リミット）、リソース要求が最小所望コンテナリソース要件、リソースが指定することができますリミットはコンテナリソースの上限を超えることはできないです。関係は、0 <=要求<=リミット <=無限の
リソース要求は、ポッドポッド要求し、すべてのコンテナのリソースです。ノードによって使用される（cAdvisorインタフェースによって得られた）ノード内のリソースの総量、およびコンピューティングリソースに基づいてスケジューリングにおけるポッドK8Sは、ノード必要があるかどうかを決定することです。
ポッドリソース要求を実行するのに十分なリソースがあることを確認するため、およびリソースの制約は、他のポッドの崩壊につながる、資源のポッド無制限の使用を防止しています。特に、パブリッククラウドのシナリオでは、常にプラットフォームにメモリをつかむために悪意のあるソフトウェアが存在します。
http://blog.csdn.net/liyingke112/article/details/77452630特定の構成を参照してください。

5.マルチポッド容器

ポッドは、主に、互いに密着して1つ以上の容器を含むことができる容器、アプリケーション指向の「論理ホスト」モデル環境を確立します。場合任意の容器が異常、異常がポッドもあろうに。

マルチポッド容器は、そう単一クラスの仮想マシンに複数のアプリケーションを有する単一の容器が、そうすべてのコンテナは、VMのリソースを共有すること、結合の程度を増加させること、したがって全体的な使いやすさを向上させる、レプリカを容易にします。

マルチコンテナは利点をポッド：

ポッド、IPアドレスとポートセクションの容器との間の空間と同じネットワーク名を使用して、より容易に共有データと通信することができ、ローカルホストが相互に通信できる発見します。

容器が失われた後に、他方が同じポッド容器で読み取ることができるが、同じランポッド（提供される場合）に貯蔵容器を共有し、ストレージボリューム内のデータは、再起動されません。

容器は、抽象化のより高いレベルを提供するアプリケーションの展開と管理を簡素化することにより、ネイティブインタフェース、ポッドと比較して、異なるコンテナは、異なるサービスを提供します。ポッドは、コピーして協調依存関係の管理を自動的に処理することができ、リソース共有をホストし、横方向に展開単位として管理しました。

6.Pod-使用

基本原則は以下のとおりです。ポッド内の複数にまたがる複数のアプリケーション
の理由：リソースの使用の合理化に基づいて、スケーラブルな容量は、容量削減戦略を拡大するアプリケーションごとに異なるがあるはずです。
容器との間一緒に実行してはならない場合は、別のポッドに入れて
容器た場合のコンポーネントが独立している前に、その後、ポッドの異なるに入れ
ポリシーは、コンテナの前に同じスケーラブルな容量でない場合、置きます異なるポッド
結論：シングルポッド、単一のコンテナアプリケーション、特別な理由がない限り

実験環境

ホストコンピューター	IPアドレス	サービス
主人	192.168.1.21	K8S
node01	192.168.1.22	K8S
node02	192.168.1.23	K8S

実験に基づいて継続的https://blog.51cto.com/14320361/2464655

二、名前空間：名前空間

デフォルトの名前空間：デフォルト

ネームスペース（名前空間）は、別の重要な概念であり、異なるパケットの共有を容易にするために、ユーザのシステム、論理的にグループ化された異なる名前空間フォーム異なる項目に「割り当てられた」ことにより、システム内のオブジェクト、グループまたはグループをkubernetesまだ別々に管理されている間、クラスタ全体のリソースを使用して。

Kubernetesクラスタが開始された後、それ以外の名前空間、ユーザーが作成したポッド、RCを指定しない場合、サービスは名前空間システムの「デフォルト」に作成された、名前空間は「デフォルト」と呼ばれるが作成されます。

名前空間をチェック1.

[root@master ~]# kubectl get namespaces

名前スペースの詳細を確認してください2。

[root@master ~]# kubectl describe ns default

名前空間を作成します3。

[root@master ~]# kubectl create ns bdqn

ルック

[root@master ~]# kubectl get namespaces

名前空間のファイルYAMLを作成します。4.

（1）表示形式

[root@master ~]# kubectl explain ns
//查看nasespace的yaml文件的格式

（2）名前空間のファイルYAMLを作成します

[root@master ~]# vim test-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test

（3）名前空間のファイルYAMLを実行します

[root@master ~]# kubectl apply -f test-ns.yaml 

（4）の外観

[root@master ~]# kubectl get ns

名前空間を削除します。4.

[root@master ~]# kubectl delete ns test 
[root@master ~]# kubectl delete -f test-ns.yaml 

注：フィード・リソース・オブジェクトを分離するための名前空間のリソース・オブジェクト、およびポッド異なる名前空間との間の通信カットオフすることができません。これは、機能的なネットワークポリシーのリソースです。

5.ビューの指定された名前空間

または-nオプションは--namespaceを使用することができます

[root@master ~]# kubectl get pod -n kube-system 
[root@master ~]# kubectl get pod --namespace kube-system 

三、ポッド

YAMLファイルのポッドを書く1

[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-app
    image: 192.168.1.21:5000/web:v1

YAMLファイルのポッドは、レプリカフィールドはサポートされていません。

（1）それを実行します

[root@master ~]# kubectl apply -f pod.yaml 

（2）查看一下

[root@master ~]# kubectl get pod

ps：这个pod因为是自己创建的，所以删除之后k8s并不会自动生成，相当于docker中创建

2.指定pod的namespace名称空间

（1）修改pod的yaml文件

[root@master ~]# vim pod.yaml
kind: Pod        #资源类型
apiVersion: v1   #api版本
metadata:
  name: test-pod    #指定控制器名称
  namespace: bdqn   #指定namespace（名称空间）
spec:
  containers:      #容器
  - name: test-app  #容器名称
    image: 192.168.1.21:5000/web:v1  #镜像

执行一下

[root@master ~]# kubectl apply -f pod.yaml 

（2）查看一下

[root@master ~]#  kubectl get pod -n bdqn 
//根据namespace名称查看

3.pod中镜像获取策略

Always：镜像标签为“laster”或镜像不存在时，总是从指定的仓库中获取镜像。

IfNotPresent：仅当本地镜像不存在时才从目标仓库下载。

Never：禁止从仓库中下载镜像，即只使用本地镜像。

注意：对于标签为“laster”或者标签不存在，其默认的镜像下载策略为“Always”，而对于其他的标签镜像，默认策略为“IfNotPresent”。

4.观察pod和service的不同并关联

（1）pod的yaml文件（指定端口）

[root@master ~]# vim pod.yaml 
kind: Pod          #资源类型
apiVersion: v1      #api版本
metadata:
  name: test-pod       #指定控制器名称
  namespace: bdqn   #指定namespace（名称空间）
spec:
  containers:                          #容器
  - name: test-app                    #容器名称
    image: 192.168.1.21:5000/web:v1   #镜像
    imagePullPolicy: IfNotPresent   #获取的策略
    ports:
    - protocol: TCP
      containerPort: 80  

<1>删除之前的pod

[root@master ~]# kubectl delete pod -n bdqn test-pod 

<2>执行一下

[root@master ~]# kubectl apply -f pod.yaml 

<3>查看一下

[root@master ~]# kubectl get pod -n bdqn 

（2）pod的yaml文件（修改端口）

[root@master ~]# vim pod.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: bdqn
spec:
  containers:
  - name: test-app
    image: 192.168.1.21:5000/web:v1
    imagePullPolicy: IfNotPresent
    ports:
    - protocol: TCP
      containerPort: 90   #改一下端口

<1>删除之前的pod

[root@master ~]# kubectl delete pod -n bdqn test-pod 

<2>执行一下

[root@master ~]# kubectl apply -f pod.yaml 

<3>查看一下

[root@master ~]# kubectl get pod -n bdqn -o wide

<4>访问一下

会发现修改的90端口并不生效，他只是一个提示字段并不生效。

（3）pod的yaml文件（添加标签）

[root@master ~]# vim pod.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: bdqn
  labels:                 #标签
    app: test-web          #标签名称
spec:
  containers:
  - name: test-app
    image: 192.168.1.21:5000/web:v1
    imagePullPolicy: IfNotPresent
    ports:
    - protocol: TCP
      containerPort: 90   #改一下端口

--------------------------------------pod---------------------------------------------

（4）编写一个service的yaml文件

[root@master ~]# vim test-svc.yaml 
apiVersion: v1      #api版本
kind: Service          #资源类型
metadata:
  name: test-svc       #指定控制器名称
  namespace: bdqn   #指定namespace（名称空间）
spec:
  selector:          #标签
    app: test-web    #标签名称（须和pod的标签名称一致）
  ports:              
  - port: 80          #宿主机端口
    targetPort: 80    #容器端口

会发现添加的80端口生效了，所以不能乱改。

<1>执行一下

[root@master ~]# kubectl apply -f test-svc.yaml

<2>查看一下

[root@master ~]# kubectl get svc -n bdqn 

[root@master ~]# kubectl describe svc -n bdqn test-svc 

<4>访问一下

[root@master ~]# curl 10.98.57.97 

--------------------------------------service---------------------------------------------

四，容器的重启策略

ポッドは、ポリシー（RestartPolicy）と内側容器のすべてのアプリケーションポッドを再起動し、のみkubeletによってノードポッドの操作や判断力を再起動します。容器又は異常なヘルスチェックのが失敗した場合、kubeletは、設定RestartPolicyに従って対応する動作を実行します。

常に：終了します（デフォルトを使用）するたびに再起動ポッドの対象;
ONFAILURE：表示されるエラーがある場合のみ、ポッドは、オブジェクトを再起動し、
決して：再起動しません。

五、ポッドデフォルトのヘルスチェック

あなたがプロセスを起動したときに、各容器は、CMD DockerfileまたはENTRYPOINTで指定されたプロセスを実行されます。戻りコードは、非ゼロの終了であれば処理はコンテナ故障を考えた場合、Kubernetesは、に基づいて行われるrestartPolicy再起動容器。

（1）書面によるヘルスチェックYAMLファイル

次のようにここでは、コンテナの故障、ポッド・コンフィギュレーション・ファイルのシナリオをシミュレートします：

[root@master ~]# vim healcheck.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healcheck
  name:  healcheck
spec:
  restartPolicy: OnFailure  #指定重启策略
  containers:
  - name:  healcheck
    image: busybox:latest
    args:                   #生成pod时运行的命令
    - /bin/sh
    - -c
    - sleep 20; exit 1 

<1>それを実行

[root@master ~]# kubectl apply -f  healcheck.yaml

<2>表情

[root@master ~]# kubectl get pod -o wide

[root@master ~]# kubectl get pod -w | grep healcheck

プロセスは、ゼロでない値のコンテナを返し、上記の例では、容器はKubernetesが再起動しないと考えられます。しかし、多くの場合がある失敗したが、プロセスは終了しません。

六、小さな実験

1）独自の名前ですべてこの名前空間では、次のK8S名前空間を作成します。

（1）名前空間を作成

[root@master ~]# kubectl create ns xgp

（2）外観

[root@master ~]# kubectl get ns xgp 

2）民間倉庫プライベートミラーを使用して、ポッドリソースオブジェクトを作成し、ミラーのダウンロード戦略ではありません：NEVER。決して：ポッドは戦略を再起動します。

[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: xgp
  labels:
    app: test-web
spec:
  restartPolicy: Never
  containers:
  - name: www
    image: 192.168.1.21:5000/web:v1
    imagePullPolicy: Never
    args:                   
    - /bin/sh
    - -c
    - sleep 90; exit 1
    ports:
    - protocol: TCP
      containerPort: 80

3）容器、無様な出口を作成した後、ポッドの最終的な状態を表示します。

YAMLのポッド上記書類の実装について（1）

[root@master ~]# kubectl apply -f pod.yaml 

（2）動的テストポッド内の情報を表示するために、NS

[root@master ~]# kubectl get pod -n xgp  -w | grep test-pod

削除テストポッド

[root@master ~]# kubectl delete pod -n xgp test-pod 

4）それらの妥当性を検証するために、サービス・リソース・オブジェクト、ポッドに関連付けてオブジェクトを作成します。

（1）YAMLファイルのポッドを変更

[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: xgp
  labels:
    app: test-web
spec:
  restartPolicy: Never
  containers:
  - name: www
    image: 192.168.1.21:5000/web:v1
    imagePullPolicy: Never
    ports:
    - protocol: TCP
      containerPort: 80

用意した文書の（1）YAMLサービス

[root@master ~]# vim svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: xgp
spec:
  selector:
    app: test-web
  ports:
  - port: 80
    targetPort: 80

（2）いくつかの実装

[root@master ~]# kubectl apply -f svc.yaml 

（3）の外観

[root@master ~]# kubectl get  pod -o wide -n xgp 

（4）アクセス

[root@master ~]# curl 10.244.1.21