このサイドカーコンテナはどのようにして[Kubernetes]に到着しましたか？

ご注意 perev。 ：ダウ・ジョーンズのエンジニアであるスコット・ラーナーが書いたこの記事では、Kubernetesの仕組み、基本コンポーネントの仕組み、相互接続および使用方法を説明する一連の資料を続けています。 今回は、Kubernetesでフックを作成するためのサンプルコードを含む実用的なメモであり、サイドカーコンテナを自動的に作成するという「口実の下で」著者によって実証されています。





（インターネットで発見されたGordon A. Maxwellによる写真。）



サイドカーコンテナーとサービスメッシュの研究を始めたとき、キーメカニズムがどのように機能するかを理解する必要がありました-サイドカーコンテナーの自動挿入。 実際、IstioやConsulなどのシステムを使用している場合、アプリケーションでコンテナーをデプロイすると、すでに構成されているEnvoyコンテナーがポッドに突然表示されます（Conduitでも同様の状況が発生します。 なに？ どうやって？ それで私の研究が始まりました...



知らない人にとっては、サイドカーコンテナは、何らかの方法でこのアプリケーションを「支援」するために、アプリケーションのコンテナの隣にデプロイされるコンテナです。 そのような使用の例は、トラフィックを管理し、TLSセッションを終了するためのプロキシ、ログとメトリックをストリーミングするためのコンテナ、セキュリティ問題をスキャンするためのコンテナなどです...機能。



続行する前に、私の期待を概説します。 この記事の目的は、Docker、Kubernetes、サービスメッシュなどの複雑さと使用シナリオを説明することではなく、これらのテクノロジーの機能を拡張する1つの強力なアプローチを示すことです。 この記事は、これらのテクノロジーの使用にすでに精通している、または少なくともそれらについて多くを読んだ人を対象としています。 実用的な部分を実際に試すには、DockerとKubernetesが既に構成されているマシンが必要です。 これを行う最も簡単な方法は、 https：//docs.docker.com/docker-for-windows/kubernetes/ （Docker for Macで動作するWindowsマニュアル）です。 （注perev .: Linuxおよび* nixシステムのユーザーの代替として、 Minikubeを提供できます。）

全体像

まず、Kubernetesを見てみましょう。





CC BY 4.0でライセンスされたKube Arch



Kubernetesに何かをデプロイする場合は、オブジェクトをkube-apiserverに送信する必要があります。 これはほとんどの場合、引数またはYAMLファイルをkubectlに渡すことで行われます。 この場合、APIサーバーはいくつかの段階を経てから、データをetcdに直接配置し、対応するタスクをスケジュールします。







このシーケンスは、サイドカーコンテナの挿入の仕組みを理解するために重要です。 特に、Kubernetesがオブジェクトを保存する前に検証し、必要に応じて変更するアドミッションコントロールに注意を払う必要があります（この手順の詳細については、 この記事の 「アクセスコントロール」の章を参照してください） 。 Kubernetesでは、ユーザー定義の検証と変更を実行できるwebhookを登録することもできます。



ただし、フックを作成および登録するプロセスはそれほど単純ではなく、十分に文書化されています。 IstioとConsulのコードを分析するだけでなく、ドキュメントの読み取りと再読み取りに数日間を費やす必要がありました。 また、一部のAPI応答のコードについては、少なくとも半日、ランダムな試行錯誤を繰り返しました。



結果が達成された後、それを皆さんと共有しないのは不公平だと思います。 シンプルであると同時に効果的です。

コード

webhookという名前は、Kubernetesで定義されたAPIを実装するHTTPエンドポイントです。 デプロイメントを処理する前にKubernetesが呼び出すことができるAPIサーバーを作成しています。 ここではいくつかの例しか利用できないため、ここでの困難に対処する必要がありました。そのうちのいくつかはKubernetesの単体テストであり、その他は巨大なコードベースの途中に隠されています...そしてすべてGoで記述されています。 しかし、私はより手頃なオプションを選択しました-Node.js：

const app = express(); app.use(bodyParser.json()); app.post('/mutate', (req, res) => { console.log(req.body) console.log(req.body.request.object) let adminResp = {response:{ allowed: true, patch: Buffer.from("[{ \"op\": \"add\", \"path\": \"/metadata/labels/foo\", \"value\": \"bar\" }]").toString('base64'), patchType: "JSONPatch", }} console.log(adminResp) res.send(adminResp) }) const server = https.createServer(options, app);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ index.js ）



APIへのパス-この場合/mutate



は任意です（将来的にKubernetesに渡されるYAMLにのみ対応する必要があります）。 彼にとって、APIサーバーから受け取ったJSONを見て理解することが重要です。 この場合、JSONから何も引き出す​​ことはありませんが、他のシナリオでは役に立つかもしれません。 上記のコードでは、JSONを更新します。 これには2つのことが必要です。

1. JSONパッチを学び、理解してください。
2. JSONパッチ式をbase64でエンコードされたバイトの配列に正しく変換します。

これが完了したら、非常に単純なオブジェクトを使用してAPIサーバーに応答を渡すだけです。 この場合、ラベルfoo=bar



ポッドに追加しfoo=bar



。

展開

さて、Kubernetes APIサーバーからのリクエストを受け入れてそれらに応答するコードがありますが、どのようにデプロイするのでしょうか？ そして、Kubernetesにこれらのリクエストをリダイレクトさせる方法は？ このようなエンドポイントは、Kubernetes APIサーバーにアクセスできる場所であればどこにでも展開できます。 最も簡単な方法は、コードをKubernetesクラスター自体にデプロイすることです。これはこの例で行います。 この例をできるだけ簡単にしようとしたので、すべてのアクションでDockerとkubectlのみを使用します。 コードを実行するコンテナを作成することから始めましょう。

 FROM node:8 USER node WORKDIR /home/node COPY index.js . COPY package.json . RUN npm install #       TLS CMD node index.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ Dockerfile ）



どうやら、ここではすべてが非常に簡単です。 ノードからコミュニティイメージを取得し、そこにコードをドロップします。 これで、簡単なアセンブリを実行できます。

 docker build . -t localserver
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のステップは、Kubernetesで展開を作成することです。

 apiVersion: apps/v1 kind: Deployment metadata: name: webhook-server spec: replicas: 1 selector: matchLabels: component: webhook-server template: metadata: labels: component: webhook-server spec: containers: - name: webhook-server imagePullPolicy: Never image: localserver
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ deployment.yaml ）



新しく作成された画像をどのように示したかに注目してください ポッドや、Kubernetesのサービスに接続できる他の何かでもあります。 次に、このサービスを定義します。

 apiVersion: v1 kind: Service metadata: name: webhook-service spec: ports: - port: 443 targetPort: 8443 selector: component: webhook-server
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、Kubernetesでは、コンテナを指す内部名でエンドポイントが表示されます。 最後のステップは、Kubernetesに、変更を加える準備ができたときにAPIサーバーにこのサービスを呼び出すように指示することです。

 apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration metadata: name: webhook webhooks: - name: webhook-service.default.svc failurePolicy: Fail clientConfig: service: name: webhook-service namespace: default path: "/mutate" #    base64-  rootCA.crt #    `cat rootCA.crt | base64 | tr -d '\n'` #    .  caBundle: "==" rules: - operations: [ "CREATE" ] apiGroups: [""] apiVersions: ["v1"] resources: ["pods"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ hook.yaml ）



ここでの名前とパスは任意ですが、できるだけ意味のあるものにしようとしました。 パスを変更すると、JavaScriptの対応するコードを変更する必要があります。 Webhook failurePolicy



もfailurePolicy



-フックがエラーを返すか失敗した場合にオブジェクトを保存するかどうかを決定します。 この場合、処理を続行しないようにKubernetesに指示しています。 最後に、ルール：Kubernetesからのアクションを期待するAPIコールに応じて変更されます。 この場合、サイドカーコンテナーの挿入をエミュレートしようとしているため、ポッドを作成するためにリクエストをインターセプトする必要があります。



以上です！ とてもシンプルですが...セキュリティはどうですか？ RBACは、この記事では取り上げていない側面の1つです。 Docker for Windows / Macに付属のMinikubeまたはKubernetesでサンプルを実行していると思います。 ただし、別の必要な要素について説明します。 Kubernetes APIサーバーはHTTPSのエンドポイントのみにアクセスするため、アプリケーションにはSSL証明書が必要です。 また、ルート証明書の証明機関が誰であるかをKubernetesに伝える必要があります。

TLS

デモンストレーションのみを目的として（!!!）、 Dockerfile



にコードを追加してルートCAを作成し、それを使用して証明書に署名します。

 RUN openssl genrsa -out rootCA.key 4096 RUN openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt \ -subj "/C=US/ST=New Jersey/L=Princeton /O=Dow Jones/OU=PIB/CN=*.default.svc/emailAddress=scott.rahner@dowjones.com" RUN openssl genrsa -out webhook.key 4096 RUN openssl req -new -key webhook.key -out webhook.csr \ -subj "/C=US/ST=New Jersey/L=Princeton /O=Dow Jones/OU=PIB/CN=webhook-service.default.svc/emailAddress=scott.rahner@dowjones.com" RUN openssl x509 -req -in webhook.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out webhook.crt -days 1024 -sha256 RUN cat rootCA.crt | base64 | tr -d '\n'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ Dockerfile ）



注：最後の手順は、base64でエンコードされたルートCAを含む1行を表示することです。 これは、フックを構成するために必要なものです。したがって、以降のテストでは、この行をcaBundle



ファイルのcaBundle



フィールドに必ずコピーしてcaBundle



。 Dockerfile



は証明書をWORKDIR



に直接スローするため、JavaScriptはそこから証明書を取得してサーバーに使用します。

 const privateKey = fs.readFileSync('webhook.key').toString(); const certificate = fs.readFileSync('webhook.crt').toString(); //… const options = {key: privateKey, cert: certificate}; const server = https.createServer(options, app);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、コードはHTTPSの起動をサポートし、Kubernetesに当社の所在地と信頼する認証機関を伝えました。 すべてをクラスターに埋め込むためだけに残ります。

 kubectl create -f deployment.yaml kubectl create -f service.yaml kubectl create -f hook.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要約する

• Deployment.yaml
  
  
  
  は、HTTPSを介してフックAPIを提供するコンテナーを起動し、オブジェクトを変更するJSONパッチを返します。
• Service.yaml
  
  
  
  は、コンテナのエンドポイントwebhook-service.default.svc
  
  
  
  提供します。
• Hook.yaml
  
  
  
  は、 https://webhook-service.default.svc/mutate
  
  
  
  場所をAPIサーバーに指示します。

ビジネスでやってみましょう！

すべてがクラスターにデプロイされます-新しいポッド/デプロイメントを追加することで実行するコードのアクションを試す時です。 すべてが正常に機能する場合、フックは追加のラベルfoo



を追加する必要があります。

 apiVersion: apps/v1 kind: Deployment metadata: name: test spec: replicas: 1 selector: matchLabels: component: test template: metadata: labels: component: test spec: containers: - name: test image: node:8 command: [ "/bin/sh", "-c", "--" ] args: [ "while true; do sleep 30; done;" ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ test.yaml ）

 kubectl create -f test.yaml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

わかりましたdeployment.apps test created



...うまくいきましたか？

 kubectl describe pods test Name: test-6f79f9f8bd-r7tbd Namespace: default Node: docker-for-desktop/192.168.65.3 Start Time: Sat, 10 Nov 2018 16:08:47 -0500 Labels: component=test foo=bar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいね！ test.yaml



は単一のラベル（ component



）が与えられましたが、結果のポッドにはcomponent



とfoo



2つが渡されました。

宿題

しかし、待ってください！ このコードを使用してサイドカーコンテナを作成しますか？ 私はサイドカーを追加する方法を示すと警告しました...そして今、私が得た知識とコードで： https : //github.com/dowjones/k8s-webhook-大胆に実験し、自動的に挿入されたサイドカーの作り方を見つけます。 とても簡単です。正しいJSONパッチを準備するだけで、テスト展開に追加のコンテナーが追加されます。 ハッピーオーケストレーション！

翻訳者からのPS

ブログもご覧ください。

• “ それでは、Kubernetesのポッドとは何ですか？ ";
• “ Kubernetesでの高可用性の提供方法 ”;
• 「 Kubernetesスケジューラは実際にどのように機能しますか？」 ";
• 「kubectlの実行が開始されるとKubernetesで何が起こりますか？」 パート1とパート2 ;
• “ KubernetesでのRBACの理解 ”;
• 「 小規模プロジェクトでのKubernetesでの経験 」 （ビデオレポート、Kubernetesの技術デバイスの紹介を含む） 。
• 「 サービスメッシュとは何ですか。なぜ必要なのですか？ 「。