いくつかの概念：
。1、ポッドのコレクションは、容器のセットで、ポッドはユニットとして管理できるようにし、PIDを共有し、IPネットワークが名前空間を切ります。
図2に示すように、容器の共有ストレージボリューム、最小単位で、コンテナを定義するYMLファイルがK8Sあります。
3、わずかにプロセスを設定マスター、少なくとも1つのノード、の準備ができて最初の実験（このブログ他の刊行物を参照されたいです）。
まず、例：
例1、一般的なポッド：
[ルート@マスター〜]＃猫pod.yaml
apiVersion：V1
種類：ポッド
メタデータ：
名前：nginxの
スペック：
コンテナ：
- 名前：nginxの
画像：nginxの
ポート：
- containerPort：80
-f pod.yamlを作成kubectl ##作成
nginxのと呼ばれるnginxの##削除されたポッドポッドを削除kubectl
例2、カスタム保存されたポッドを持ちます：
[ルート@マスター〜]＃猫vol.yaml
apiVersion：V1
種類：ポッド
メタデータ：
名前：Redisの
スペック：
コンテナ：
- 名前：Redisの
画像：リピート
volumeMounts：
- 名前：Redisの永続ストレージ
MOUNTPATH：/データ/ Redisの
ボリューム：
- 名前：Redisの永続ストレージ
emptyDir：{}
[ルート@マスター〜]＃のkubectl -f vol.yamlを作成
そのノードポッドで作成した[ルート@マスター〜]＃kubectl GETポッドRedisの-o YAML ##ビュー
例3のラベルとポッド：
キーは、オブジェクト（例えば、POD）である/値のペアを識別し、オブジェクト組織のサブセットを選択するために使用されます。
[ルート@マスター〜]＃猫labels.yaml
apiVersion：V1
種類：ポッド
メタデータ：
名前：nginxの-ラベル
ラベル：
アプリ：nginxの、ラベル
スペック：
コンテナ：
- 名前：nginxの-ラベル
画像：nginxの
ポート：
- containerPort：80
例4、複製コントローラー：
サイズ;オンラインアップグレード、マルチリリースバージョンの追跡ポッドを指定された実行時間の数のいずれか、コンテナが再スケジュールすることを確認します。
[ルート@マスター〜]＃猫rc.yaml
apiVersion：V1
種類：ReplicationController
メタデータ：
名前：それ以外の場合は、アプリケーションが間違ったタイムサービスを指定することができ、同様のアプリとラベルと一致している##のnginx-コントローラ。
スペック：
レプリカ：2
セレクタ：
アプリ：nginxの-RC ##は、秋がダウンして再び自動的に実行する場合ベースのnginx-RCコンテナは、通常であると判断し
テンプレート：
メタデータ：
ラベル：
アプリ：nginxの-rcの##のラベルはnginxの-RCをします
スペック：
コンテナ：
- 名前：nginxの-RCの＃コンテナという名前のnginx-RC
画像：nginxの
ポート：
- containerPort：80
それを削除してから見て：
全体のrcを削除した後、RCが停止しました。
[ルート@マスター〜]＃のkubectl RCのnginxのコントローラを削除します
実施例5、サービス：
別のポッドはどのようなサービスを提供するために、これらのポッドを見つけるにはPODS？
サービス：1、ポッドのシリーズは、抽象的で、そのアクセスルールを定義することができます; 2、固定のIPアドレスとDNSドメイン名; 3、環境変数とDNSディスカバリサービスを通じて、4、負荷分散、
図5に示すように、外部サービス-clusterip（またはマスターホストにアクセスするためのノード）\ NodePort（内部サーバ用）\ロードバランサ（外部アクセス）
[ルート@マスター〜]＃猫service.yaml ##ノートケース
apiVersion：V1
種類：サービス
メタデータ：
名前：nginxのサービス
スペック：
ポート：
- ポート：8000 ##ポートの外部アクセス、それはそうでない場合にのみノードをアクセスすることができ、外部IPアクセスカードを追加することが最良です
targetPort：ポッドポートにアクセスするための80＃
プロトコル：TCP
セレクタ：
アプリ：nginxの-ラベルポッドにアクセスするには＃マーク
、ビューのアクセスを作成します。
例6--1、RC +サービス（これはクラスタの外部機器にアクセスNodePortポートマッピングのタイプとすることができる：IPおよび物理ホストクラスタIPのいずれでもよい）、この実験は、実施例4に基づいて行きました。
[ルート@マスター〜]＃猫サービスrc.yaml
apiVersion：V1
種類：サービス
メタデータ：
名前：nginxのサービス-RC
ラベル：
アプリ：nginxのサービス-RC
スペック：
タイプ：NodePort
セレクタ：
アプリ：nginxの-rcの## RCは、セレクタの名前であり、オハイオ州のメタデータ指定した名前でインスタンスをでrcありません
ポート：
- 名前：HTTP
nodePort：30000
ポート：80
プロトコル：TCP
アクセス効果：
例6--2、RC +サービス2（例えば、唯一の任意のマシンクラスタにアクセスすることができる）、この実験は、実験の共存下、無衝突で、実施例4に基づいて行きました。
[ルート@マスター〜]＃猫サービスrc2.yaml
apiVersion：V1
種類：サービス
メタデータ：
名前：nginxのサービス-RC2
ラベル：
アプリ：nginxのサービス-RC2
スペック：
セレクタ：
アプリ：nginxの-rcの## rcのドキュメントメタデータは名前を付けることはできません。
ポート：
- ポート：8033
targetPort：80
プロトコル：TCP
コマンドを使用してサービスを作成します。
-fサービスrc2.yamlを作成kubectl
実施例7、秘密：
[ルート@マスター〜]＃猫secret.yaml
apiVersion：V1
種類：秘密
メタデータ：
名前：mysecret
タイプ：不透明は##ランダムユーザーデータを表します。
データ：
API_KEY：bWVnYV9zZWNyZXRfa2V5
API_SECRET：cmVhbGx5X3NlY3JldF92YWx1ZTE =
または（大文字と小文字に注意してください）：
[ルート@マスター〜]＃猫secret2.yaml
apiVersion：V1
種類：秘密
メタデータ：
名前：mysecret2
タイプ：不透明
データ：
USERNAME：ルート
PASSWORD：cmVhbGx5X3NlY3JldF92YWx1ZTE =
リソース管理-resources、ヘルスモニタリング-liveness /即応プローブ、フック関数：組織のリソース：
Kubectlバッチ処理：オンラインアプリケーションのアップグレードとロールバック：
トラックは、安定したバージョンを表し、動的ポッドの数を調整するのレプリカを表しています。
kubectlスケールのRC nginxのコントローラ--replicas = 5
ポッド##ビューポッドを記述kubectl
kubectlログポッド＃ログを見ます
ポッドは、##広い-oなど、すべてのコンテナの名前、IPの基本的な状況をチェックしてもらうkubectl
ドッカーネットワークは、ブリッジ検査情報のブリッジ##を検査します。
ポッドのnginx-RC-9hhmb ##チェックの詳細のポッドを説明kubectl。
kubectlポートフォワードnginxの8080：80位（コンテナが再起動後に消える）外部デバイスにアクセスするためには、コンテナにポートをマッピングします。
例えば図8に示すように、展開（更新画像を容易にするため）。
[ルート@マスター〜]＃猫deployment.yaml
apiVersion：アプリケーション/ V1
種類：展開
メタデータ：
名前：nginxの展開
ラベル：
アプリ：nginxの-DEP
スペック：
レプリカ：3
セレクタ：
matchLabels：
アプリ：nginxの-DEP
テンプレート：
メタデータ：
ラベル：
アプリ：nginxの-DEP
スペック：
コンテナ：
- 名前：nginxの-DEP
画像：nginxの：1.12.2
ポート：
- containerPort：80
いくつかの一般的に使用されるコマンドは、################# ############
ポッドを取得kubectl
展開を取得kubectl
kubectl GET RS
展開-o広い取得kubectl
##ミラーリングされたバージョンの更新は、アップグレードして結果を確認します：
kubectl設定イメージ展開nginxの-展開nginxの-DEP = nginxの：1.13
##ロールバックミラーとチェック（3バージョン1を覆う、最新バージョンです）。
kubectlロールアウト履歴展開nginxの展開
kubectlの展開は、展開nginxの展開を元に戻します
展開-o広い取得kubectl
外部からのアクセスに##コンテナマッピングサービス：
展開nginxの展開を公開kubectl --type = NodePort
##は、元の展開という名前のnginxの展開を削除する必要はありません
##第二に、ネットワークを実現（現実には、多くのロードバランスマルチ）：
私たちは、このような不変として画像と拡張IPとポート・コンテナを更新したいので、直接管理ポッドを使用しないでください、
サービスへのこの使用：
CLUSTERIP：のみをマスタノードとノードがアクセスすることができます。
NodePort：外部ノードがネットワークと通信もアクセスすることができます。
ロードバランサ：クラウドサービスプロバイダが提供することができます。
サービスを示す（ラベルを持っている必要があり、容器がサービスとして使用することができない）ポッドに直接マップ外部アクセスコマンド：例1
（コマンドは--type = NodePortで作成された後、SVCネットワークタイプNodePort、デフォルトCLUSTERIP、唯一のアクセス・ノードである）kubectlポッドnginxの-ラベルを公開し、以下のサービスを作成します（コンテナのnginx-ラベルという名前の一種であり、ポッド種類、種別型展開は、我々が展開を使用する必要がある場合は、正しいことにする）、および参照してください。
次のnginx-ラベルという名前のポッドを除去した後のテスト、IPサービスの作成が変更されていないが、アクセスすることはできません。
IPの、同じコンフィギュレーションファイルの下のポッドを再作成するポッドは変更しましたが、IPのサービスはまだ動作し、変わっていません。
別の###：（ランニングnginxの展開に対応する）展開コマンドファイルのオンライン変更、ホットアップデート：
効果はすぐに修正##した後、古いコンテナが破壊されkubectl編集展開nginxの展開は、保存した後、終了し、新しいコンテナがアップになります。
##他の一般的に使用されるコマンド：
状況の-o広い##のチェックノードノードを取得しますkubectl。
kubectlノードノード1 ##のチェックノードのノード1の場合について説明。
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ 終わり ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃