O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

OpenShift.RUN Summer 10 tetsuyasd

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 47 Anúncio

OpenShift.RUN Summer 10 tetsuyasd

Baixar para ler offline

2020/09/24に行われたOpenShift.RUN Summer #10で発表した
kubernetesクラスタのログ分析と可視化で知っておくべきこと~Elastic Stackの特性と注意点~
の発表スライドです

2020/09/24に行われたOpenShift.RUN Summer #10で発表した
kubernetesクラスタのログ分析と可視化で知っておくべきこと~Elastic Stackの特性と注意点~
の発表スライドです

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Semelhante a OpenShift.RUN Summer 10 tetsuyasd (14)

Anúncio

Mais recentes (20)

OpenShift.RUN Summer 10 tetsuyasd

  1. 1. kubernetesクラスタのログ分析と可視化 で知っておくべきこと @tetsuyasd OpenShift.Run Summer #10 2020/09/24 ~Elastic Stackの特性と注意点~
  2. 2. Who am I ? 2 名前: 惣道 哲也 (そうどう てつや) Twitter: @tetsuyasd 所属: 日本ヒューレット・パッカード株式会社 Pointnext事業統括 職務: オープンソース関連いろいろ(調査、検証、構築、提案) - Cloud / Container / Data Analytics / etc… …… おや? Elasticsearch実践ガイド の ようすが…! Elastic Stack実践ガイド [Elasticsearch/Kibana編] 2020/8/7発売 (Impress Top Gear) Elasticsearch7対応ES6対応
  3. 3. Agenda (40min) 3 1. kubernetesにおけるログ分析 2. Elastic Stackのおさらい 3. ログ管理コンポーネントの構成での注意点 – 想定する前提知識 – k8s / OpenShiftをインストールし、アプリのデプロイや 運用管理を経験したことがある – ログの管理についての基礎的な知識・経験がある – ElasticsearchやElastic Stackについて何となく知っている ■ 今日のゴール k8s / OpenShift でElastic Stackを使った ログ管理をする際の基本的考え方や 構成がイメージできる 「Elasic Slack 完全に理解した!」
  4. 4. 今日お話ししないこと – k8sのLoggingアーキテクチャ – Grafana Lokiや各種PaaS/SaaSなど、Elastic Stack以外のログ管理・分析ツール – 上記トピックについては以下のスライドがおすすめ! –Kubernetes Logging入門 (CNDT2019) @yosshi_ さん 4 https://speakerdeck.com/yosshi_/kubernetes-loggingru-men
  5. 5. 1. kubernetesにおけるログ分析
  6. 6. k8sクラスタインストール – 巷にあふれる知見 6
  7. 7. k8sクラスタインストール、のその先 – 運用管理(Day2 Operation)が大事 – 分散システムに固有の難しさ – いわゆる「Observability(可観測性)」と呼ばれるもの – 監視 (Monitoring) – ログ管理 (Logging) – トレーシング (Tracing) – その他にも – クラスタアップデート – 開発ワークフローとデプロイメント – 構成管理とバックアップ – 各種メンテナンス(証明書アップデートなど・・・) 7 https://landscape.cncf.io/ 今日は主にここのお話
  8. 8. Azure ログ管理の代表的な構成パターン① – Public Cloud PaaSパターン – GKE + stackdriver – EKS + CloudWatch Logs – AKS + Azure Monitor Logs (LogAnalytics) – 各種ログの収集・可視化・分析はPaaSとして提供されるケースがほとんど 8 Container Engine stackdriver AWS Cloud VPC Amazon Elastic Kubernetes Service Amazon CloudWatch Azure Kubernetes Service Azure Monitor Logs GCP AWS Azure
  9. 9. ログ管理の代表的な構成パターン② – Grafanaパターン – もともとPrometheus + Grafanaでメトリクスを収集・可視化していたパターンに、ログ管理がAdd-on – Promtail (or Fluentd) + Grafana Loki + Grafana 9 tagベースでのログ検索 (例:{app: nginx} ) 正規表現検索 (例: status (4|5)¥d¥d )
  10. 10. ログ管理の代表的な構成パターン③ – Elastic Stack Observabilityパターン – Beats and/or Logstash + Elasticsearch + Kibana – OpenShift でも Cluster Logging として実装されている – ただし、Beatsの代わりにFluentdを採用 10 本日は、このElasticパターンをご紹介 文字列フィールドはインデックスによる高速検索が可能 メトリクス(数値)フィールドは集計・分析を高速に処理 Elastic Stackについては この後解説
  11. 11. 2. Elastic Stackのおさらい
  12. 12. Elastic Stackとは 12 可視化と管理 蓄積・検索・分析 収集Elastic Stack – 全文検索から、ログ・メトリクスの収集・可視化・分析まで、幅広いユースケースで使われる – オンプレ、VM、Cloud、コンテナどこでも展開可能(マネージドなSaaSもあります) 汎用ログ転送 (JVM実装、豊富な変換機能) 用途特化型軽量ログシッパー (go実装、小フットプリント)
  13. 13. Elastic Stackとは – ライセンスはどうなってるの? – Core機能はOSS (“Apache License 2.0”) – Elastic社による付加機能(X-Packと呼ばれていたもの)は ”Elastic License”だが、コードはOpen –Basic機能は無償利用可 – バージョンの考え方は? – Elastic Stackファミリ全体で統合されたバージョニング –2020/09/23時点の最新版は7.9.1 – メンテナンス対象は最新2世代(現在の6.x) –8.0がリリースされると6.xのメンテナンスは終了される予定 – 特にElasticsearchは内部でApache Luceneを使っており、 Luceneのバージョンに依存する –2世代前のLuceneインデックスに対する後方互換性がない –ESも同様に2世代以上古いのインデックスは利用できない点に注意 13 基本機能 ・全文検索 ・クラスタリング など Elasticsearchサブスクリプション Apache License 2.0 オプション機能 (旧X-Pack) Basic (無償) Elastic License ・認証 ・監視 など Gold/Plutinum (有償) ・アラート ・機械学習 など Enterprise (有償) ・Endpoint Security など https://www.elastic.co/jp/subscriptions
  14. 14. Elastic Stack活用ユースケースの例 – もともとはサイトやドキュメント等の全文検索用途が主 – アプリログ・インフラ基盤ログの収集・可視化・分析のニーズが急増 – この他にもユースケースパターンは多数あります 14 クエリ 業務システム ログ保管 インデックス 可視化 ・分析 ログ収集(変換) ログ インデックス Logstashはシステム外に保管されたログ に対してETL的に利用するケースが多い 業務システム ログ・メトリクス 収集 Beatsは軽量のため、各システム内に Agentとして動作させてログ収集もできる (コンテナの場合、Sidecar or DaemonSet) 複数の業務システム(インフラ・アプリ) のメトリクスやログを一元的に可視化、 検索、分析するダッシュボードとして利用
  15. 15. Elasticsearchの簡単な紹介 – Javaベースの全文検索ソフトウェア – 内部でApache Luceneを利用 – JSONフォーマットに対応した柔軟性の高いドキュメント指向データベース – インデックス登録・クエリともにREST APIインターフェースを利用 – 複数ノードからなるクラスタ構成が可能 – インデックスデータは分散配置(シャーディング)が可能 – レプリカ(複製)による高可用性の実現 – 可視化、ログ収集など周辺ソフトウェアが充実 – “Observability”全体をカバーできるポートフォリオ 15 REST API index/query { “item": “book", “price“: “750” } Powered by document
  16. 16. Elasticsearchのインデックス登録とクエリの例 – 1件のドキュメントをインデックス(my_index)に登録する例 16 $ curl -XPOST ’http://localhost:9200/my_index/_doc/’ -H ’Content-Type: application/json’ -d ’ { "user": "kimchy", "post_date": "2009-11-15T13:12:00", "message": "Trying out Elasticsearch, so far so good?" }’ $ curl -XGET ’http://localhost:9200/my_index/_search’ -H ’Content-Type: application/json’ -d ’ { "query": { "match": { "message": "Elasticsearch" } } }’ – 特定のフィールド(message)に含まれる文字列を検索するクエリの例 複数のkey:valueからなる 任意のJSONドキュメントを 登録できる 特定の文字列を含む ドキュメントをクエリで 検索できる
  17. 17. Elasticsearchのインデックスとシャードとレプリカについて – 登録するドキュメントは「インデックス」に保存される – 「インデックス」は複数の「シャード」に分割して構成される – さらに、各シャードは複製(「レプリカ」)される – シャード数、レプリカ数は任意に設定できる 17 Cluster Node1 Node2 Node3 Primary Shard #0 Primary Shard #2 Replica Shard #0 Replica Shard #1 Primary Shard #1 Replica Shard #2 シャード数:3、レプリカ数:1で構成されたインデックスの例 Point1: Scalability インデックスのデータは複数の シャードに分散して管理される Point2: Availability 各シャードデータはレプリカ シャードに複製して管理される シャード配置は自動管理 (ノードダウン時のリバランス等も自動)
  18. 18. Elasticsearchのノード種別とクラスタ構成 – 主なノード種別 – Masterノード:クラスタとノードの管理 – Dataノード:データ保持、登録・クエリ処理の実行 – Ingestノード:登録前データの加工・変換(≒Logstash) – 小規模構成では上記役割を兼ねることも多い – その他、リクエストディスパッチのみするcoordination onlyノードや 機械学習ジョブが実行されるMLノードなどもある – クラスタ構成 – Masterノード3台以上でHAクラスタ構成 –Build-inのクラスタコーディネーション機構を持つ – Dataノードは任意にスケールアウト可能 –シャード分散による拡張性、レプリカ複製による可用性 18 Node1 Node2 Node3 = アクティブなMasterノード Node4 Node5 Node6 Node7 Node8 Node9 type: master type: data Node10 Node11 type: ingest 複数ノードで構成されたクラスタの例 node.master: true node.data: false node.ingest: false node.ml: false Master用elasticsearch.yaml (抜粋) Cluster
  19. 19. Elasticsearchにおけるドキュメントの構造 19 新しいドキュメントを格納 Index Document Field1 Field2 Field3 … Document Field1 Field2 Field3 … … … Index – インデックスの登録とデータ型定義(マッピング)の仕組み – 各インデックスごとに固有のマッピングを定義できる – 定義を省略しても自動で型推定して登録してくれる { "item" : "banana", "price": "300.0", "when" : "Oct 8" } Index "mappings": { "properties": { “item“ : {"type":“text" }, “price": {"type":“float"}, “when“ : {"type":“date" } } } 登録ドキュメントの例 マッピング定義の例
  20. 20. text型とkeyword型の違い – text型 – 登録時にAnalyzerにより単語分割されて、転置インデックスに格納される – 検索時もクエリフレーズが単語分割され、それをもとに転置インデックス から検索される – 一部の単語がマッチすれば検索にはヒットする – 関連度の高さがスコアで表現され、スコアの高い順に応答が返される – keyword型 – 格納時に分割処理が行われない – 検索ワードに「完全一致」しないとヒットしない – メールアドレス、固有名詞などで利用される 20 "query": { "match": { “dajare”: “暗くて渋い逸品" } } Word Document ウクライナ 1,4 もう 1,5,8 暗い 1,3,7 コンテナ 2,4,7 中 7 転置インデックス ドキュメント登録(text型) 形態素解析 ドキュメント クエリ text型で登録すると 単語に分割して格納 関連度スコアに応じて ドキュメントがヒット 形態素解析 { “dajare”: “ウクライナはもう暗いな” } クエリ結果 { “dajare”: “ウクライナはもう暗いな” }
  21. 21. Elasticsearchに割り当てるメモリサイズ – JVM Heap – クラスタ、インデックスデータ等のメタデータをキャッシュ – OS cache(ページキャッシュ) – Luceneのシャード(ファイル)をOSのキャッシュに持つ – 【重要】 メモリサイジングのTips – 物理メモリ量の半分までにする – いわゆる「32GBの壁」に注意(後述) – 【new】 Elasticsearch 7.7でJVM Heapの利用効率が劇的に向上(10~100倍) (*1) – 従来は、Luceneインデックスファイルサイズ1TBにつきHeapが約3GB程度(1/30程度)必要 (Hot index) – Elasticsearch 7.7の改良により、わずか30~300MB(1/3000~1/300程度)あればOKに 21 Node Lucene File Index shard shard shard shard Memory OS Cache JVM Heap <50% <約32GB (*1) https://www.elastic.co/jp/blog/significantly-decrease-your-elasticsearch-heap-memory-usage
  22. 22. Elasticsearchに割り当てるメモリサイズ – 「JVM Heap 32GBの壁」問題 – “Compressed OOPs”(圧縮オブジェクト参照)の恩恵が受けられるのが「約」32GBまで – Compressed OOPsとは? – 64bitアーキテクチャ(LP64)のマシンでは本来ヒープオブジェクトの管理アドレス(ポインタ)は64bitで表現するが無駄も多い – 節約のため、ヒープのアドレスを8byte単位に制限して(Object Alignment)、32bitで表現(実際には0x1000を乗ずる) – 従来32bitでは4GB(=2^32)しか表現できないものが、35bit(=2^35≒32GB)のアドレスを表すことができるようになる – JVMのバージョンやJVM実装、GCの種類などにより、ピッタリ32GBとはならないので、31GB程度にしておくのが無難 22https://www.baeldung.com/jvm-compressed-oops [2020-03-30T07:26:14,269][INFO ][o.e.e.NodeEnvironment] [vm01] heap size [31.9gb], compressed ordinary object pointers [true] 起動時のログに [true] と出ていればcoops有効 Qiitaにて、 「Elasticsearchにおける「32GBメモリの壁」 の境界線を調べる」 という記事をまとめたので参照ください https://qiita.com/tetsuyasodo/items/6eab589a406f882572d0
  23. 23. 【注意】 Elasticsearchのバージョンの違い 23 – バージョンの違いにより動作が変わったり、エラーになることも – PaaSや特定製品に付随されるElasticsearchではバージョンが最新でないケースもある –OpenShift 4.5付随のCluster LoggingではElasticsearch 6.8.1 (OSS版) を利用 – ブログなどの情報にも古いバージョンの内容が多い –特にバージョン6→7で多くの変更があるため、落とし穴になりやすい – ドキュメントタイプの廃止(6.xまではタイプ名の指定ができたが、7.xではAPI上でもタイプ名の扱いを廃止 *1) – クラスタコーディネーションシステムが刷新され、設定ファイルのsyntaxも変更に – インデックス作成時のシャード数のデフォルトが5→1に – 検索クエリのレスポンスフォーマットが地味に変更 – などなど・・・ – ちなみに、Kibanaは変化が激しすぎて書き切れないため省略。。。 (*1) https://www.elastic.co/jp/blog/moving-from-types-to-typeless-apis-in-elasticsearch-7-0
  24. 24. 3. ログ管理コンポーネントの構成での注意点
  25. 25. 【再掲】 ログ管理の代表的な構成パターン③ – Elastic Stack Observabilityパターン – Beats and/or Logstash + Elasticsearch + Kibana – OpenShift でも Cluster Logging として実装されている – ただし、Beatsの代わりにFluentdを利用 25 この2つの構成の注意点 /Tipsを紹介
  26. 26. ログ管理コンポーネントの導入 (OpenShift Cluster Logging) – OpenShiftならOperatorHubから”Cluster Logging”をInstallすればおk? →「Operatorとしては」それでOK、ただし別途Loggingインスタンスのデプロイも必要 ※依存Operatorとして、事前にElasticsearch Operatorの導入も必要 26
  27. 27. ログ管理コンポーネントの導入 (OpenShift Cluster Logging) – ”Cluster Logging”インスタンスの展開 – CRDに基づいて、各種EFKリソースが展開される – ”logStore(Elasticsearch)”の構成の注意点 – 高可用性構成にするためにはnodeCountを3以上に – storageClassNameを指定して永続化する – 思っている量の8倍くらい(※主観です)メモリが必要 –requests/limitsで指定(右例では省略されてます) – その他の主なリソース – collection(Fluentd):DaemonSetで各Node上に展開 – curation(Curator):古いインデックスの自動削除ジョブ等を実行 – visualization(Kibana):可視化と分析用のGUI 27 curator
  28. 28. ログ管理コンポーネントの導入 (Elastic Stack/ECK) – ECKを使えばOperatorを利用して、Elastic Stack Observabilityパターン構成がすぐ作れます – 以上 – ・・・ECKって何? 28 https://www.elastic.co/jp/blog/introducing-elastic-cloud-on-kubernetes-the-elasticsearch-operator-and-beyond
  29. 29. Elastic Cloud on Kubernetes(ECK) とは – Kubernetes Operatorパターンに基づいてElastic Stackをk8s/OCP上に容易に展開できるproduct – Basicライセンスでの利用が可能 – k8s 1.12以降/OpenShift 3.11以降サポート – GKE/AKS/EKSでも動作 29 • クラスタのスケールアウト/スケールイン • クラスタ設定・ノード設定の変更 • PV / ローカルストレージの利用 • CronJobを利用した定期的な自動スナップショット取得 • デフォルトで通信暗号化などのセキュア設定が有効化 など… https://www.elastic.co/jp/blog/introducing-elastic-cloud-on-kubernetes-the- elasticsearch-operator-and-beyond
  30. 30. ECKの導入手順 – 超ざっくり解説 – – Elasticsearchクラスタデプロイ用yamlの例 (例: my-es-cluster.yaml) 30 apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: quickstart-es spec: version: 7.9.1 nodeSets: - name: default count: 3 config: node.master: true node.data: true node.ingest: true apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: quickstart-kb spec: version: 7.9.1 count: 1 elasticsearchRef: name: quickstart-es – Kibanaデプロイ用yamlの例 (例: my-kibana.yaml) カスタムリソース カスタムリソース $ kubectl apply -f https://download.elastic.co/downloads/eck/1.2.1/all-in-one.yaml – ECK Operatorの導入 $ kubectl apply –f my-es-cluster.yaml $ kubectl apply –f my-kibana.yaml – よしなにデプロイ
  31. 31. ECKの導入手順 – 超ざっくり解説 – 31 – ElasticsearchクラスタとKibanaの完成
  32. 32. ECKの導入手順 – 超ざっくり解説 – 32 apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: es-with-sufficient-memory spec: version: 7.9.1 nodeSets: - name: default count: 3 podTemplate: spec: containers: - name: elasticsearch env: - name: ES_JAVA_OPTS value: -Xms31g -Xmx31g resources: requests: memory: 64Gi limits: memory: 64Gi – (参考)もし潤沢なメモリを持つノードがあれば・・・ – Podに割り当てるメモリ(resources) – JVM Heapに割り当てるメモリ(ES_JAVA_OPTS) – <50% かつ <32GBになるよう注意
  33. 33. ログ収集をBeatsのカスタムリソースで自動化 – 例:filebeatのautodiscover – hints.enabled: true とすると、 Pod側のannotationをヒントに 自動ログ収集が行える (次ページに例を記載) – BeatsからES/Kibanaへの連携 もインスタンス名参照を書くだけ でOK(カスタムリソース間連携) 33 apiVersion: beat.k8s.elastic.co/v1beta1 kind: Beat metadata: name: filebeat spec: type: filebeat version: 7.9.0 elasticsearchRef.name: quickstart-es kibanaRef.name: quickstart-kb config: filebeat.autodiscover.providers: - type: kubernetes node: ${NODE_NAME} hints: enabled: true default_config: type: container paths: - /var/log/containers/*${data.kubernetes.container.id}.log processors: - add_cloud_metadata: {} - add_host_metadata: {} … Pod定義に付与されたannotationを ヒントに自動ログ収集を行う カスタムリソース Elasticsearch/Kibanaとの連携は ここに参照先を書くだけ ホストやクラウド基盤の情報 (region/zone/instance名等)も付加
  34. 34. k8sクラスタへの各種Beatsの展開 34 PodP PodP PodP PodP DaemonSetDS filebeat DaemonSetDS metricbeat PodP PodP PodP PodP DaemonSetDS filebeat DaemonSetDS metricbeat PodP PodP PodP PodP DaemonSetDS filebeat DaemonSetDS metricbeat – DaemonSetとして各ノードごとに展開 filebeat 各ノード上のコンテナログ /journalログを収集・送信 metricbeat 各ノード上のリソースと、 kube-state-metricsから 収集したリソースを送信 Node1 Node2 Node3 spec: replica: 3 template: metadata: labels: app: my-nginx annotations: co.elastic.logs/enabled: “true” co.elastic.logs/module: “nginx” annotationが付与されたPodの コンテナログを自動収集
  35. 35. KibanaのObservabilityメニューから可視化、分析 35 PodやNode単位でヒートマップ を表示し、その単位でログやメ トリクスを表示できる filebeatが収集したログをスト リーム表示させつつ、横断検索 や絞り込み検索が可能 Filebeatやmetricbeatと連携す ることでObservabilityダッシュ ボードが自動的に構成される
  36. 36. 各種Beats取り揃えてます – Filebeat – autodiscover機能でコンテナログ自動収集 – Metricbeat – Master/Workerノードのリソース監視(CPU/mem/NW/filesystem) – k8sリソース監視 (Nodes, Pods, Containers, Volumes) – Heartbeat – Elasticsearch/Kibanaのサービス監視(port tcp/9200,tcp/5601) – Jounalbeat – Master/Workerノードのjournalログの監視 – Auditbeat – ホストのファイルシステム改ざん検知 36 収集戦隊ビーツマンっ!
  37. 37. ログ管理コンポーネントの導入におけるデザインパターン – Master用PodはpodAntiAffinityでノード分散させる – Data領域となるストレージ/PVCは、特定のPodに紐づける – Pod再起動時にPVが再利用できないと、シャードの復旧(リバランス)が 必要になるため – ECKではStatefulSetを利用し、OCPではDeploymentをoperatorが制御 – PV向けストレージは速度や冗長構成の観点からLocalも良い選択肢 – オンプレ環境のOCPの場合、LocalStorage Operatorが利用可能 (*1) – k8s Masterノードの情報も収集する場合、Taintsの有無に注意 – MasterノードにTaintsが設定されている場合、PodにToleration設定が必要 – 例) OCPの場合のToleration設定 37 https://github.com/elastic/cloud-on-k8s/tree/master/docs/design ECKのGitHubリポジトリにはデザインノートが あり、このような設計過程の議論が残されて いて非常に参考になる tolerations: - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule (*1) https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.5/html/storage/persistent-storage-using-local-volume
  38. 38. まとめ
  39. 39. ふりかえり:クラウドネイティブなログ管理とは – ログ管理の対象となるシステムの特性を考える – 分散、疎結合なシステム – イミュータブル(≒後からAgentなどを追加導入できない) – Podのスケーラビリティ、回復性 – 自動化された運用 – (マルチテナンシー) – 可観測性を満たすためのアプローチ – ログ・メトリクスは各ノードごとにDaemonSetで取得(右図参照) –ログにタグまたはnamespaceなどでラベル付けして収集 –メトリクスも各ノードごとkube-state-metricsなどで収集 – タグやnamespaceベースでアドホックに検索できるUI –ログ、メトリクス(、トレーシング)の間を相互に遷移できるとなお良い – 構成パターンはいくつかあるが、おおむね類似のアプローチに 39 https://speakerdeck.com/yosshi_/kubernetes-loggingru-men ノードごとにまとめて ログ取得する ■(参考)Kubernetes Logging入門(@yosshi_さん)
  40. 40. まとめ 40 –k8s/OpenShiftを導入後の運用管理(Day2 Operation)としてのログ管理の概要・構成 –Elastic Stackの概要とログ管理ソリューションへの活用 –k8s/OpenShiftに導入する際の注意点/Tips – (特にElasticsearchの)特徴を知って、正しく使おう –クラウドネイティブなシステムにおけるログ(メトリクス)管理の考え方とアプローチ 日比野恒さん執筆 Logstach/Beats編もぜひ 2020/9/16発売 (Impress Top Gear)
  41. 41. ご清聴ありがとうございました
  42. 42. 42 本資料に関するお問い合わせ 42 @tetsuyasd Mailto: tetsuya.sodo@hpe.com Elasticsearch,Kibana,Logstash,Beats,Elastic Stackは、Elasticsearch BVの米国およびその他の国における登録商標または商標です。 Openshiftは、Red Hat, Inc.の米国およびその他の国における登録商標または商標です。 その他、本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。 本発表内容に関して、ご質問等があればお問い合わせ下さい。 また、内容に関しては個人の意見に基づくものであり、所属組織団体の公式見解とは異なる場合がございます点、ご了承 下さい。
  43. 43. Appendix. OCP4.5以降で強化された Elasticsearchセキュリティについて
  44. 44. OCP4.5でのCluster LoggingでデプロイされるElasticsearch – セキュリティが強化され、クラスタやインデックスに気軽にアクセスできなくなりました – 内部でElasticsearch 6.8.1が動いており、さらにOpen Distro for ElasticsearchのSecurityモジュールが動いている模様… – KibanaからREST APIが投げられるDev Tools/Console機能でも、インデックス一覧コマンドがpermissionエラーに・・・ 44 “GET _cat/indices” コマンドでインデックス一覧 を取得しようとするとsecurity exceptionが発生
  45. 45. OCP4.5でのCluster LoggingでデプロイされるElasticsearch – セキュリティが強化され、クラスタやインデックスに気軽にアクセスできなくなりました – 何が困るか? 45 “index pattern”としてインデックス名を登録 しないとKibanaでログ検索できないのに インデックス名が(勘でしか)わからない /(^o^)\オワタ
  46. 46. OCP4.5でのCluster LoggingでデプロイされるElasticsearch – 【回避策】 Podに潜り込んでadmin証明書を引数にして直接curlコマンドを叩けば任意のリクエストが実行可能 46 $ oc rsh pod/elasticsearch-cdm-v7iju121-1-5f8f9b6b7b-wl8v7 Defaulting container name to elasticsearch. Use 'oc describe pod/elasticsearch-cdm-v7iju121-1-5f8f9b6b7b-wl8v7 -n openshift-logging' to see all of the containers in this pod. sh-4.2$ secret_dir=/etc/elasticsearch/secret/ sh-4.2$ curl -k -s --cacert $secret_dir/admin-ca --cert $secret_dir/admin-cert ¥ --key $secret_dir/admin-key -H Content-type:application/json ¥ https://localhost:9200/_cat/indices green open audit-000001 i5TPByjySxuljcbCkZxxqw 3 1 0 0 1.5kb 783b green open .kibana_92668751_admin lPEY1kU8SNiwoeATyzDNWA 3 1 2 0 38.5kb 19.2kb green open .security S7I17OenSyKw792ISFhPqA 1 1 5 0 59.9kb 29.9kb green open infra-000001 rKkCvxS2RFuGZ3QlTWbNVw 3 1 2407345 0 2.3gb 1.1gb green open app-000001 VFTU4q-EQKGjPvaFibssjw 3 1 0 0 1.5kb 783b green open .kibana_1 pk7FzSE7T0ekQ2yujbvOOA 1 1 1 0 7.7kb 3.8kb sh-4.2$ インデックス一覧の取得 ※機能検証の目的でのみ実行しています。サポート可否にはご注意ください。
  47. 47. OCP4.5でのCluster LoggingでデプロイされるElasticsearch – 【回避策】 Podに潜り込んでadmin証明書を引数にして直接curlコマンドを叩けば任意のリクエストが実行可能 47 sh-4.2$ curl -k -s --cacert $secret_dir/admin-ca --cert $secret_dir/admin-cert ¥ --key $secret_dir/admin-key -H Content-type:application/json ¥ https://localhost:9200/app-*/_settings | jq . { "app-000001": { "settings": { "index": { "refresh_interval": "5s", "number_of_shards": "3", … "number_of_replicas": "1", "uuid": "pAoI-P84SPKJmcmaaX5aEw", … } } } } インデックス設定の取得 ※機能検証の目的でのみ実行しています。サポート可否にはご注意ください。

×