「本番環境でEnvoyを導入するためにやったこと」というタイトルでLTしてきました。発表資料はこちら自分はCotrolPlaneを特に用意していないので、Envoyを気軽に導入したい人には参考になるかと思います。Decksetで発表しようとしたら全表示されなかったので、急遽旧verのpdf化した資料で発表することになったのが、反省point。会場のEnvoy利用者は1割程度な感じでした。Istio利用者は数%程度だったのではないでしょうか。DataPlaneとしてのEnvoyについてというより、CotrolPlaneについての方が関心が多いのかなという印象をうけました。Istioも1.5からIstiodが入ったりして、覚えるコンポーネントが少しは減ると思うので、そろそろ触ってみようかな。手動で管理していたCloudDNSをコード管理したかったので、terraformerを使ってコード化しました。プログラミングGoで何か書いた時にCIの設定をまとめてみた。いい方法がありそうなので、ブラッシュアップしていきたい。.travis.ymltravisの設定は以下の用にする。lintチェックさせる。configは以下の内容で大体十分。githubのリポジトリのownerとnameを入れておきます。providerを使用して確認していく。terraformコマンドで構築する前にクレデンシャル情報を環境変数に渡しておくのを忘れずに。プロバイダ用のバイナリをダウンロードする。何かtfファイルを編集したらインスタンスが再作成されてしまったなんてことが起きるので注意。destroyも要確認。変数variableで変数の定義ができる。ローカル変数が定義できる。variableはコマンド実行時に変数を上書きできるがlocalsは上書きできない違いがある。apply時にターミナル上で値が確認できるようになる。他にはmoduleから値を取得する時に使う。i-090d4a8d3ec3fac74データソースデータソースを使うと外部データを参照できる。最新のAMIを取得している。"t3.micro"}providerAWS、GCP、Azure、Openstackなど構築する際、そのAPIの違いを吸収するものがプロバイダ。mojuleを使ってするとこうなる。セキュリティグループへの参照を追加し、EC2インスタンスと紐づけます。形式で他のリソースの値を参照できます。本番環境と開発環境でインスタンスタイプを切り替えたい時。'env=dev'ただ環境を分けたい時はディレクトリで分けたりしてもよいかな。文字列操作やリスト操作、よくある処理が組み込み関数として提供されている。してスクリプトで外に出す。ファイルと同じディレクトリに置く。ファイルを読み込んでくれる。実行時に値を埋め込むテンプレート機能がある。テンプレートファイル化してみる。インストールパッケージを差し替えられるように、「package」変数を定義する。変更した差分を検出して、必要な部分だけ変更できることが確認できた。この判断をtfstateファイルで行っている。生成するファイルで、現在の状態が記録されている。記述されたコードの内容に差分があれば、その差分のみを変更するよう振る舞う。実行していれば作成される。中身を見るとJSON文字列に、現在の状態が記述されているのがわかる。全リソース再作成が起きるおそれがあるので、リモートのストレージを、バックエンドとして利用しましょう。AWSならS3などを利用しましょう。作り、事前作成したバケットを指定します。}}リモートのバックエンドとして使用するS3バケットには、バージョニング設定をすることが強く推奨されます。S3に保存すれば、tfstateファイルから、いつでも以前の状態に戻せるようにもなります。リソース削除できます。実行には注意しましょう。モジュール化の仕組みがあります。ファイルを作成します。配下のmoduleを環境毎に再利用することも可能になります。モジュールを実装します。番ポートを許可したセキュリティグループを定義してみます。モジュールのインタフェースは次のとおりです。ファイルを以下のように実装します。モジュール利用側のディレクトリで実行します。モジュールを使用する場合、もうひと手間必要です。コマンドを実行して、モジュールを事前に取得しておく必要があります。ciなどを利用してinitで失敗したらbuildが失敗するようにする運用がいいと思う。CIで回してパッケージ管理の準備までしてしまおうというもの。必要なので作成しておく。Datadogdatadogの記事をみるとGKEなどのkubernatesをdatadogでモニタリングするには各ノードにdatadog-agentをdeamonsetで常駐させるのが一般的らしい。Pod間通信でメトリクスを取ってくるようです。datadogのkubernatesのintegrationのページにも書いてありまする。spec.selectorが必要になります。metricsをDogStatsD経由で送信するため、8125/UDPをHost(ノード)に公開しますTraceの機能も同様に他のpodから使いたいため8126/TCPをHost(ノード)に開ける。API_KEYはSecretから取得。作成コマンドは以下参照。manifestを書いて、それにk8sクラスタに当てる必要がある。manifest管理をどうするかの問題が発生するが、今回はhelmを使ってインストールをする。helmfileを用いたdatadog-agentインストールますhelmとはK8sのパッケージ管理ツール。installコマンドに適時引数で設定情報を与え、簡単に自分のクラスタに導入(Release)することができる。releasesを管理してくれるもの。ように冪等に管理してくれるもの。datadog-agentをクラスタに配置する場合は以下のYAMLを書くだけ。gcloudコマンドでログインして、クラスタのクレデンシャルとって、helmを当てていく流れ。CI側の環境変数に入れておく。同様に、サービスアカウントの認証情報がローカルシステムに保存され、指定したアカウントがCloudSDKの構成のアクティブなアカウントに設定される。サービスアカウントは事前に作成しておく(DatadogのGCPのintegrationするときに必要になる。フラグは先頭の項目の右側に挿入する。クラスタに対して認証を行う。実行して、再取得することでキャッシュをリフレッシュさせる。わたってhelm-diffプラグインを実行。helm-diffパッケージが必要。--dry-runHelmfileは実行中にさまざまなイベントをトリガーとする。イベントが発生すると、argsを指定してコマンドを実行することで、関連するフックが実行される。syncサブコマンドは、helmfileの説明に従ってクラスタの状態を同期する。デフォルトのhelmfileはhelmfile.yaml。フラグを指定することで渡すことができる。必要に応じて、secretsを復号化してhelmチャートの値として使用する。指定されたチャートリポジトリを更新し、参照されているローカルチャートの依存関係も更新する。releaseが存在するかどうかに応じてインストールまたはアップグレードすることができる。インストールができる。何かhelmで追加したくなったらhelmfileに書いていくことになる。実はまだ機能追加されてない?helpに特に出てこない。kubeadm(ver1.14以上)前回kubeadmでマルチマスターのクラスタ構築をしたが、kubeadm1.14で証明書の発行と配布がされるようになったので試してみた。CPU以上クラスタ内のすべてのマシン間の完全なネットワーク接続(パブリックまたはプライベートネットワークは問題なし)ノードごとに固有のホスト名、MACアドレス、およびproduct_uuid。マシンでは特定のポートを開けとくスワップ無効(kubeletを正しく動作させるためにスワップを無効にする。トラフィックを分散させるためにそれらの前にHAPRoxyロードバランサーを配置する必要がある。LBにするサーバにSSHで接続します。haproxy3つのKubernetesマスターノード間でトラフィックを負荷分散するようにHAProxyを設定。checkHAProxyを再起動。クラスタ内で利用するオーバーレイネットワーク用にカーネルパラメータを変更しておきます。トラフィックが誤ってルーティングされるという問題を報告しています。/etc/kubernetes/kubeadmkubeadm-configを作成する。使用するKubernetesバージョンに設定する必要があります。ロードバランサのアドレスまたはDNSとポートを一致させる必要があり。Kubernetesのバージョンを一致させることがお勧め。IPはproxyサーバのIPです。10.64.0.0/18指定されたupload-certsと設定でクラスタを初期化します。--experimental-upload-certsこの出力をテキストファイルにコピーし。後で他のコントロールプレーンノードをクラスタに参加させるために必要になるのでメモ。復号化を可能にするのでメモ。d54f93a776345163398ec944fc67021517e96f11e3a59fb3d659ba5ab8f60b17利用するユーザで以下を実行。kubeconfigコマンドを実行する推奨のkubectlアクセス用。$HOME/.kube/configkube-systemネームスペースのkubeadm-certシークレットを調べる。etcd、kube-apiserver、およびサービスアカウントの証明書が表示されます。これは一時的なkubeadmトークンと相関しています。そのトークンが期限切れになると、このsecretも失効します。利用可能なトークンリスト一覧を取得する。上記のステップの所有者参照であることに注意してください。これは結合トークンではなく、kubeadm-certsでttlを有効にするプロキシです。ruf1ngトークンを使用する必要があります。podのCIDRでインストールする。PodがRunningであることを確認する。Nodeを追加するメモっておいた以下のコマンドを実行する。最初に既存のkubeadmトークンをすべて削除する。新規で構築する場合は不要だが、これは、Kubernetesクラスターが既に実行されているときにマスターを追加する方法です。kubeadm-certsシークレットの有効期限が切れて削除されたため、以前に記録されたjoinコマンドは機能しません。暗号化キーは無効になり、joinトークンは機能しなくなります。GROUPS10分のTTLで新しいトークンを作成します。以下のIPはロードバランサーのホストを反映している必要があります。initのupload-certsフェーズを実行。key:d0e3299a47812ebe52497e4d47676786c39460b0e137844c87862059f5436f7dMasterに追加したいNodeにSSH接続し、前の手順の出力を使用して、コントロールプレーンへのjoinコマンドを実行します。1台ずつpodが組み込まれて完了したことを確認してから実行していくこと。v1.14.0ROLESがnoneなのでworkerと付与してもいい。v1.14.0etcdの冗長化はされないので、するなら別にしないとだめ。みなさんどうされているか、よければおしえてください。以下にsampleを載せてあります。対応のために、今回は以下のレスポンスヘッダーを付与させます。endpoint_configurationの設定が必要になる。GatewayのResourcesの設定TerraformのProviderを参考に作成するだけで大丈夫。つける以外はTerraformのProviderを参考に作成するだけで大丈夫。Access-Control-Allow-Originをレスポンスヘッダに付与させます。aws_api_gateway_method_responseに依存する。前述のレスポンスヘッダーをメソッドのレスポンスヘッダーとして返す。ヘッダーを返すようにすること。広範なサポートを有効にすることはよく考えること。任意のサーバーを指定可能なのでできるならその方がよいので。Formを例にしている。aws_api_gateway_method_responseに依存する。}WAFのRuleはIP制限。同一IPアドレスから5分間に2000(最低値)を超えたリクエストをトリガー。Resoucesを使う必要がある。RULEに該当したらBLOCKさせる設定をする。Gatewayでも繋ぐことができた。ALBで使うproviderで今回はIP指定もないので使わない。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。