OpenShift.RUN Summer 10 tetsuyasd

kubernetesクラスタのログ分析と可視化
で知っておくべきこと
@tetsuyasd
OpenShift.Run Summer #10
2020/09/24
～Elastic Stackの特性と注意点～

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対応

Agenda (40min)
3
1. kubernetesにおけるログ分析
2. Elastic Stackのおさらい
3. ログ管理コンポーネントの構成での注意点
– 想定する前提知識
– k8s / OpenShiftをインストールし、アプリのデプロイや
運用管理を経験したことがある
– ログの管理についての基礎的な知識・経験がある
– ElasticsearchやElastic Stackについて何となく知っている
■ 今日のゴール
k8s / OpenShift でElastic Stackを使った
ログ管理をする際の基本的考え方や
構成がイメージできる
「Elasic Slack 完全に理解した！」

今日お話ししないこと
– k8sのLoggingアーキテクチャ
– Grafana Lokiや各種PaaS/SaaSなど、Elastic Stack以外のログ管理・分析ツール
– 上記トピックについては以下のスライドがおすすめ！
–Kubernetes Logging入門 (CNDT2019) @yosshi_ さん
4
https://speakerdeck.com/yosshi_/kubernetes-loggingru-men

1. kubernetesにおけるログ分析

k8sクラスタインストール
– 巷にあふれる知見
6

k8sクラスタインストール、のその先
– 運用管理（Day2 Operation）が大事
– 分散システムに固有の難しさ
– いわゆる「Observability（可観測性）」と呼ばれるもの
– 監視 (Monitoring)
– ログ管理 (Logging)
– トレーシング (Tracing)
– その他にも
– クラスタアップデート
– 開発ワークフローとデプロイメント
– 構成管理とバックアップ
– 各種メンテナンス（証明書アップデートなど・・・）
7
https://landscape.cncf.io/
今日は主にここのお話

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

ログ管理の代表的な構成パターン②
– Grafanaパターン
– もともとPrometheus + Grafanaでメトリクスを収集・可視化していたパターンに、ログ管理がAdd-on
– Promtail (or Fluentd) + Grafana Loki + Grafana
9
tagベースでのログ検索
(例：{app: nginx} )
正規表現検索
(例： status (4|5)¥d¥d )

ログ管理の代表的な構成パターン③
– Elastic Stack Observabilityパターン
– Beats and/or Logstash + Elasticsearch + Kibana
– OpenShift でも Cluster Logging として実装されている
– ただし、Beatsの代わりにFluentdを採用
10
本日は、このElasticパターンをご紹介
文字列フィールドはインデックスによる高速検索が可能
メトリクス（数値）フィールドは集計・分析を高速に処理
Elastic Stackについては
この後解説

2. Elastic Stackのおさらい

Elastic Stackとは
12
可視化と管理
蓄積・検索・分析
収集Elastic Stack
– 全文検索から、ログ・メトリクスの収集・可視化・分析まで、幅広いユースケースで使われる
– オンプレ、VM、Cloud、コンテナどこでも展開可能（マネージドなSaaSもあります）
汎用ログ転送
（JVM実装、豊富な変換機能）
用途特化型軽量ログシッパー
（go実装、小フットプリント）

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

Elastic Stack活用ユースケースの例
– もともとはサイトやドキュメント等の全文検索用途が主
– アプリログ・インフラ基盤ログの収集・可視化・分析のニーズが急増
– この他にもユースケースパターンは多数あります
14
クエリ
業務システム
ログ保管
インデックス
可視化
・分析
ログ収集(変換)
ログ
インデックス
Logstashはシステム外に保管されたログ
に対してETL的に利用するケースが多い
業務システム
ログ・メトリクス
収集
Beatsは軽量のため、各システム内に
Agentとして動作させてログ収集もできる
（コンテナの場合、Sidecar or DaemonSet）
複数の業務システム（インフラ・アプリ）
のメトリクスやログを一元的に可視化、
検索、分析するダッシュボードとして利用

Elasticsearchの簡単な紹介
– Javaベースの全文検索ソフトウェア
– 内部でApache Luceneを利用
– JSONフォーマットに対応した柔軟性の高いドキュメント指向データベース
– インデックス登録・クエリともにREST APIインターフェースを利用
– 複数ノードからなるクラスタ構成が可能
– インデックスデータは分散配置（シャーディング）が可能
– レプリカ（複製）による高可用性の実現
– 可視化、ログ収集など周辺ソフトウェアが充実
– “Observability”全体をカバーできるポートフォリオ
15
REST API
index/query
{ “item": “book",
“price“: “750” }
Powered by
document

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ドキュメントを
登録できる
特定の文字列を含む
ドキュメントをクエリで
検索できる

Elasticsearchのインデックスとシャードとレプリカについて
– 登録するドキュメントは「インデックス」に保存される
– 「インデックス」は複数の「シャード」に分割して構成される
– さらに、各シャードは複製（「レプリカ」）される
– シャード数、レプリカ数は任意に設定できる
17
Cluster
Node1 Node2 Node3
Primary
Shard #0
Primary
Shard #2
Replica
Shard #0
Replica
Shard #1
Primary
Shard #1
Replica
Shard #2
シャード数：３、レプリカ数：１で構成されたインデックスの例
Point1: Scalability
インデックスのデータは複数の
シャードに分散して管理される
Point2: Availability
各シャードデータはレプリカ
シャードに複製して管理される
シャード配置は自動管理
（ノードダウン時のリバランス等も自動）

Elasticsearchのノード種別とクラスタ構成
– 主なノード種別
– Masterノード：クラスタとノードの管理
– Dataノード：データ保持、登録・クエリ処理の実行
– Ingestノード：登録前データの加工・変換(≒Logstash)
– 小規模構成では上記役割を兼ねることも多い
– その他、リクエストディスパッチのみするcoordination onlyノードや
機械学習ジョブが実行されるMLノードなどもある
– クラスタ構成
– Masterノード３台以上で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

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" }
}
}
登録ドキュメントの例
マッピング定義の例

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”:
“ウクライナはもう暗いな” }

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

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

【注意】 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

3. ログ管理コンポーネントの構成での注意点

【再掲】ログ管理の代表的な構成パターン③
– Elastic Stack Observabilityパターン
– Beats and/or Logstash + Elasticsearch + Kibana
– OpenShift でも Cluster Logging として実装されている
– ただし、Beatsの代わりにFluentdを利用
25
この２つの構成の注意点
/Tipsを紹介

ログ管理コンポーネントの導入 (OpenShift Cluster Logging)
– OpenShiftならOperatorHubから”Cluster Logging”をInstallすればおｋ？
→「Operatorとしては」それでOK、ただし別途Loggingインスタンスのデプロイも必要
※依存Operatorとして、事前にElasticsearch Operatorの導入も必要
26

ログ管理コンポーネントの導入 (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

ログ管理コンポーネントの導入 (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

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

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
– ElasticsearchクラスタとKibanaの完成

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になるよう注意

ログ収集を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名等)も付加

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の
コンテナログを自動収集

KibanaのObservabilityメニューから可視化、分析
35
PodやNode単位でヒートマップ
を表示し、その単位でログやメ
トリクスを表示できる
filebeatが収集したログをスト
リーム表示させつつ、横断検索
や絞り込み検索が可能
Filebeatやmetricbeatと連携す
ることでObservabilityダッシュ
ボードが自動的に構成される

各種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
収集戦隊ビーツマンっ！

ログ管理コンポーネントの導入におけるデザインパターン
– 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

ふりかえり：クラウドネイティブなログ管理とは
– ログ管理の対象となるシステムの特性を考える
– 分散、疎結合なシステム
– イミュータブル（≒後からAgentなどを追加導入できない）
– Podのスケーラビリティ、回復性
– 自動化された運用
– （マルチテナンシー）
– 可観測性を満たすためのアプローチ
– ログ・メトリクスは各ノードごとにDaemonSetで取得（右図参照）
–ログにタグまたはnamespaceなどでラベル付けして収集
–メトリクスも各ノードごとkube-state-metricsなどで収集
– タグやnamespaceベースでアドホックに検索できるUI
–ログ、メトリクス（、トレーシング）の間を相互に遷移できるとなお良い
– 構成パターンはいくつかあるが、おおむね類似のアプローチに
39
https://speakerdeck.com/yosshi_/kubernetes-loggingru-men
ノードごとにまとめて
ログ取得する
■（参考）Kubernetes Logging入門(@yosshi_さん)

まとめ
40
–k8s/OpenShiftを導入後の運用管理(Day2 Operation)としてのログ管理の概要・構成
–Elastic Stackの概要とログ管理ソリューションへの活用
–k8s/OpenShiftに導入する際の注意点/Tips
– （特にElasticsearchの）特徴を知って、正しく使おう
–クラウドネイティブなシステムにおけるログ（メトリクス）管理の考え方とアプローチ
日比野恒さん執筆
Logstach/Beats編もぜひ
2020/9/16発売
(Impress Top Gear)

ご清聴ありがとうございました

42
本資料に関するお問い合わせ
42
@tetsuyasd
Mailto: tetsuya.sodo@hpe.com
Elasticsearch,Kibana,Logstash,Beats,Elastic Stackは、Elasticsearch BVの米国およびその他の国における登録商標または商標です。
Openshiftは、Red Hat, Inc.の米国およびその他の国における登録商標または商標です。
その他、本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。
本発表内容に関して、ご質問等があればお問い合わせ下さい。
また、内容に関しては個人の意見に基づくものであり、所属組織団体の公式見解とは異なる場合がございます点、ご了承
下さい。

Appendix. OCP4.5以降で強化された
Elasticsearchセキュリティについて

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
“index pattern”としてインデックス名を登録
しないとKibanaでログ検索できないのに
インデックス名が（勘でしか）わからない
／(^o^)＼ｵﾜﾀ

– 【回避策】 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$
インデックス一覧の取得
※機能検証の目的でのみ実行しています。サポート可否にはご注意ください。

– 【回避策】 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",
…
}
}
}
}
インデックス設定の取得
※機能検証の目的でのみ実行しています。サポート可否にはご注意ください。

OpenShift.RUN Summer 10 tetsuyasd

Recommended

Recommended

More Related Content

Featured

Featured (20)

OpenShift.RUN Summer 10 tetsuyasd