CNCF サンドボックスプロダクト
1517本ノック！
Cloud Native Developers JP
1
CloudNative Days Tokyo 2019
CNCF Sandboxとは？
2
Image source: https://www.cncf.io/projects/
CNCF Sandbox プロジェクト https://www.cncf.io/sandbox-projects/
3
4
KubeEdgeのしくみ
5
https://github.com/kubeedge/kubeedge
エッジを制御するためのController
CloudHubとEdgeHubがクラウドとエッジの通信を担う
エッジ側で動作するオーケストレーター。
エッジ側のアプリケーン的処理はここで可動するコンテナで実行
HTTP／MQTTからの入力を仲介するServiceBus／EventBus
デバイスのステータスをクラウド側と同期
クラウドパート
エッジパート
KubeEdgeの少し詳しい話
6
7
Virtual Kubeletのしくみ
8
https://github.com/virtual-kubelet/virtual-kubelet
Virtual Kubeletの少し詳しい話
9
10
GitOpsとは
11
https://speakerdeck.com/hhiroshell/ochacafe-number-1
ここにFluxを使う
Fluxの特長
12
13
この@jacopenさんの図が全てを物語ってる。
14
実際Dockerfileはアプリのレポジトリに当然入ると思いますが、
これにより、Dockerfileを書く責務（+CI/CD）がアプリエンジニアの責務になりがち、
だけどこのフローは本当に正しいのか？とはnnao45も思う。
コンテンツデリバリの簡素化、高速化を邪魔したくない。
15
そこで、
16
Knativeの例
17
apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: cnb-example-build
spec:
source:
git:
url: https://github.com/my-user/my-repo
revision: master
template:
name: buildpacks-cnb
arguments:
- name: IMAGE
value: us.gcr.io/my-project/my-app
- name: BUILDER_IMAGE
value: cloudfoundry/cnb:bionic
- name: CACHE
value: my-cache
volumes:
- name: my-cache
persistentVolumeClaim:
claimName: my-volume-claim
コードのレポジトリを指定する。
コードをどうビルドするか、どの言語化はbuild packsが検知してやってくれる。
コンテナのビルドフェーズで、
レジストリ登録もする。
build packsはビルダーイメージを使ってビルドを行う。
参考資料
18
特徴
19
アーキテクチャ
20
21
ジョブの発行を定義した関数。
リソースを引数に持ち、この場合はGithubのPushイベント
Brigadeのplaybookの例
CIを走らせるジョブを作る。
このジョブはBrigadeが走るクラスタのジョブ
CIジョブのイメージを設定することができる。
このイメージの記法はOCIに準ずる（今回はDocker）。
今回はPython3のCIなので、
それをするようなタスクを組むと、上から実行してくれる。
ランナーのtasksで実行された時のログは、
kubeletが拾えてストリームとしてkubectl logsなどで閲覧可
設定したCICDジョブを実行できる。
22
BrigadeのProjectsの例
GitHubやGitLabなどからのWebhookによる発火も便利だが、
ジョブは、brigというCLIツールから発火もできる。
他のCICDパイプラインのような、if thenなworkflowもサポートしており、それもJSとして記述できる。
例えば特定のノードで（例えばCICDを動かす時にだけ起動させるVirtual kubeletとか）、リソースを指定して、などkubeのリソースを指定してタスクを動かすことも可能。
参考資料
ソースコード
23
24
Network Service Mes….
用途
25
L2/L3サービスメッシュ？
🤔
26
L2/L3サービスメッシュ？
（個人的にはCloud Native Network Functionの方がイメージにあっている）
🤔
27
Network Service Mesh全体像
28
Network Service
Network Service Endpoint
L2/L3 Connection
Object
Of
Interest
特定のKubernetesリソースに与えたいL2/L3サービス全体。以後NS。
例えば、セキュアなイントラネット接続。
特定のKubernetesリソースに与えたいL2/L3サービス終端。以後NSE。
例えば、VPNのトンネル終端とか、VXLANのVTEP。
特定のKubernetesリソースとNSEを繋ぐ、L2/L3のコネクティビティ。
要はルーティングなのだが、Network Service Meshの場合はそれを「Kubernetesのラベル」で表現する。
Network Service Mesh設定例
29
Network Service
Network Service Endpoint
Object
Of
Interest
Firewall Service
Network Service Endpoint
VPN Service
Secure Intranet Service
Network Service Mesh設定例
30
Network Service
Network Service Endpoint
Object
Of
Interest
L2/L3 Connection
Firewall Service
Network Service Endpoint
VPN Service
Secure Intranet Service
app:firewall
app:vpn
Network Service Mesh設定例
31
Network Service
Network Service Endpoint
Object
Of
Interest
L2/L3 Connection
Firewall Service
Network Service Endpoint
VPN Service
Secure Intranet Service
kind: NetworkService
apiVersion: V1
metadata:
name: secure-intranet-connectivity
spec:
payload: IP
matches:
- match:
sourceSelector:
app: firewall
route:
- destination:
destinationSelector:
app: vpn-gateway
app:firewall
app:vpn
Network Service Mesh設定例
32
Network Service
Network Service Endpoint
Object
Of
Interest
L2/L3 Connection
Firewall Service
Network Service Endpoint
VPN Service
Secure Intranet Service
app:firewall
app:vpn
L2/L3 Connection
Network Service Mesh設定例
33
Network Service
Network Service Endpoint
Object
Of
Interest
L2/L3 Connection
Firewall Service
Network Service Endpoint
VPN Service
Secure Intranet Service
app:firewall
app:vpn
L2/L3 Connection
kind: NetworkService
metadata:
name: secure-intranet-connectivity
spec:
payload: IP
matches:
- match:
sourceSelector:
app: firewall
route:
- destination:
destinationSelector:
app: vpn-gateway
- match:
route:
- destination:
destinationSelector:
app: firewall
Network Service Meshまとめ
34
Network Service Meshまとめ
35
参考資料
36
37
Falcoのしくみ
k8s API Server
eBPF
Kernel
User
falcosecurity/falco
ルールファイル(YAML)
falco-probe�kernel module
sysdig/�falco-event-generator
（テスト用イベントの生成）
38
Container-�Optimized OS
Kubernetes Response Engine
🚨
GKE (Container-Optimized-OS) へのHelmでのインストール
39
Falcoルールファイルの構成
Falcoのルールファイルは下記の3種類の要素からなるYAML
40
⚠︎早速イベントが検出されました
Warning Log files were tampered (user=root command=pos_writer.rb:* -Eascii-8bit:ascii-8bit /usr/sbin/google-fluentd --under-supervisor file=/var/log/gcp-journald-kubelet.pos) k8s.ns=kube-system k8s.pod=fluentd-gcp-v3.1.1-snn2q container=118edbfb76d8
/var/log/gcp-journald-node-problem-detector.posについても同様に検出対応するルール Clear Log Activities を確認する
41
- rule: Clear Log Activities� desc: Detect clearing of critical log files� condition: >� open_write and access_log_files and evt.arg.flags contains "O_TRUNC"� output: >� Log files were tampered (user=%user.name command=%proc.cmdline file=%fd.name)� priority:� WARNING� tags: [file, mitre_defense_evasion]
- macro: open_write
condition: (evt.type=open or evt.type=openat) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0
- macro: access_log_files
condition: (fd.directory in (log_directories) or fd.filename in (log_files))
- list: log_directories
items: [/var/log, /dev/log]
- list: log_files
items: [syslog, auth.log, secure, kern.log, cron, user.log, dpkg.log, last.log, yum.log, access_log, mysql.log, mysqld.log]
42
is_open_writeはFalcoの関数だが、それ以外は open(at) システムコールの仕様に沿って書かれている
Clear Log Activitiesルールの構成
rule:�Clear Log Activities
macro:�open_write
macro:�access_log_files
list:�log_directories
list:�log_files
evt.arg.flags contains "O_TRUNC"
43
and
or
Position fileの書き換え誤検出対策
devブランチのルールファイルを参考に、ホワイトリストを追加する
- rule: Clear Log Activities
condition: >
open_write and access_log_files and evt.arg.flags contains "O_TRUNC" and not allowed_clear_log_files
- macro: allowed_clear_log_files
condition: (fd.name in (gke_pos_files))
- list: gke_pos_files� items: [/var/log/gcp-journald-node-problem-detector.pos, /var/log/gcp-journald-kubelet.pos]
別の指定方法として proc.cmdline startswith pos_writer.rb も考えられる
44
45
前提とするアプリケーション構成
46
☁
マネージドDB
このアプリをデバッグしたい
🐳
Kubernetesにおける開発環境の選択肢
47
| 💻 ローカル | ☁ クラウド |
1 | minikubeや�Docker Compose | - |
2 | - | 開発用クラスタ�全てのアプリを含む |
3 | 開発中のアプリと�Telepresence | 開発用クラスタ�他の依存アプリはこちら |
🐳
🐳
🐳
開発環境の比較
48
| 開発中のアプリの差し替え | クラスタ内の他のAPI、�マネージドサービスへのアクセス |
minikube, Composeの�ローカルクラスタ | ○ ローカルで完結 | △ エミュレータがない、機能が限定されるサービスがある |
マネージドKubernetes�開発用クラスタ | × CIやリモートのレジストリを経由する必要あり | ○ アクセス可能 |
開発用クラスタと�Telepresence | ○ ローカルで完結 | ○ アクセス可能 |
☁
☁
検証シナリオ
49
☁
curl
nginx (reverse proxy)
nginx.conf�proxy_pass http://backend-1:8080;
backend-1�nginx (server)
backend-2�Apache
Telepresenceでコンテナを差し替える
50
☁
curl
datawire/telepresence-k8s
ラベルやポートは元のDeployから�引き継がれServiceの設定変更は不要
🍎
🐳
nginx.conf�proxy_pass http://backend-2:8080;
backend-1�nginx (server)
backend-2�Apache
ローカルコンテナから�クラスタ内DNS名の名前解決も可能
元のDeployment (replicas=0)
コマンド実行例
$ telepresence --swap-deployment devapp --docker-run demoapp:backend2 nginx -g "daemon off;"
T: Volumes are rooted at $TELEPRESENCE_ROOT. See https://telepresence.io/howto/volumes.html for
T: details.
T: Starting network proxy to cluster by swapping out Deployment devapp with a proxy
T: Forwarding remote port 8080 to local port 8080.
T: Setup complete. Launching your container.
51
差し替えたいDeployment名
基本はdocker runと同様にオプションを記述
52
Dragonflyを使ったイメージのPull
53
image source: https://d7y.io/img/architecture.png, Apache License 2.0
大元のイメージレジストリ
レジストリにアクセスするのはSupernodeに限定し、上流への負荷を軽減
dfget, daemonがdockerd / pouchd（Alibabaのコンテナランタイム）の代わりにイメージレイヤをダウンロード
54
SPIFFE(SPIRE)で何を解決したいか？
55
56
SPIFFE(SPIRE)で何を解決したいか？
簡単に言うと・・・
⇒ クラウドネイティブ(スケーラブル)な環境でセキュアな認証を実現
※頻出キーワード: Zero Trust Network
57
SPIFFE が定義する標準仕様
58
URI形式を使ってシステムを表す
X.509形式のTLS証明書
59
@hiyosiさんの資料、KubeCon EU@Barcelonaでも紹介されてました！�
ご参考) KubeCon EU 2019 @Barcelona
60
61
62
63
Container Attached Storage (CAS)
64
Container Attached Storage (CAS) / OpenEBS
65
CASのアーキテクチャ
OpenEBS アーキテクチャ
66
CAS(ストレージ)エンジンの種類
CASエンジン - cStor
==> 包括的なストレージ管理� (K8sのCRで実現)
67
CAS メリット
68
Non CAS Storage
CAS Storage
Kubernetesの管理対象としてアプリ，ストレージを同様に扱える
ワークロード毎に
独自のコントローラ
I/O負荷を軽減
ロックイン回避
OpenEBS コントロールプレーンの動作
69
PVCの生成を検出
メトリクスの�エンドポイントを提供
etcdと連携する�サイドカー
PVの作成
を要求
Pod(Controller/Replica)�を作成
MayaOnline
70
71
CloudEventsが目指す世界
72
ServerlessをBorderlessへ
CloudEventsのコア仕様（v0.3）
73
{
"specversion" : "0.3",
"type" : "com.github.pull.create",
"source" : "https://github.com/cloudevents/spec/pull",
"subject" : "123",
"id" : "A234-1234-1234",
"time" : "2018-04-05T17:31:00Z",
"comexampleextension1" : "value",
"comexampleextension2" : {
"othervalue": 5
},
"datacontenttype" : "text/xml",
"data" : "<much wow=\"xml\"/>"
}
データ
メタデータ
CloudEventsの少し詳しい話
74
75
OpenTracing＋OpenCensus＝OpenTelemetry
76
OpenTelemetryが目指す世界
77
Prometheus
Datadog
New Relic
mackerel
Stackdriver
CloudWatch
OpenTelemetryに対応しておけば�どの監視ツールでも対応できるようになる
※2019年9月末 v1.0 リリース予定
言語実装
78
Google, Uber
79
OpenMetricsのしくみ
80
# HELP http_requests_total The total number of HTTP requests.�# TYPE http_requests_total counter�http_requests_total{method="post",code="200"} 1027 1395066363000�http_requests_total{method="post",code="400"} 3 1395066363000
message Person {� required string name = 1;� required int32 id = 2;� optional string email = 3;�}
Text Representation
Protocol Buffers
OpenMetricsがあると嬉しいこと
81
Prometheus
Datadog
New Relic
mackerel
Stackdriver
CloudWatch
OpenMetrics
OpenMetricsに対応しておけば�どの監視ツールでも対応できるようになる
82
Cortexのしくみ
83
Distributor
Ruler
Ingester
Querier
Proxy
Cortexのアーキテクチャ
84
85
Thanosのしくみ
86
Prometheusに対して
Thanos Sidecarをつける
Querier経由で参照のリクエストを投げる
Thanos Sidecarが、Prometheusが�集めたmetricsをBucketにアップロードする
Storeを経由することで
Bucketのデータを時系列データとして扱える
Bucketのデータの
圧縮とダウンサンプリングをする
Thanosのアーキテクチャ
87
88
Fin.
以降はスライドのテンプレ
89
（これは中扉）
90
91
92
93
94
95