「車輪の再実装」って言葉が好き（実践はできてない）

Weekly Log 9

今週もただの記録

今週読んだ記事・サイト

GoのためのGo

Golangの静的解析のための記事。 日本語としてこれ以上詳しく書いているサイトは見たことがない。

一人トランザクション技術 Advent Calendar 2016 - Qiita

最近分散システムとDBへの興味が増していて、その一環として読んだ。 まだ半分そこそこしか読めてないが、RDBであってもACID特性はそこまで守られていないという話 *1 が驚きだった.

  • QUIC is now RFC 9000 | Fastly QUICがとうとう標準化されたよ！というFastlyの記事。 このpostの最後にしびれた。かっこいい

But for now, those of us at Fastly and elsewhere who have been deeply engaged in this process over the past half decade or more should soak in the moment and rejoice in having played a part in internet history.

やってみて理解する kubernetes の Graceful Node Shutdown - Qiita

先日リリースされたkubernetes v1.21でbeta版となったGraceful Node Shutdownについて。 いろんな環境で試したけど、いずれも何かしら問題があったよ。という話。 説明の途中でD-Busが出てきて、D-Busいつか勉強しないとなぁという気持ちになった。 D-Busに限らず、この辺りのLinuxの機能はあまり知らないので少しずつ勉強していきたい。

今週の疑問＆調査

  • ssd等には内部に揮発性のキャッシュがあるらしいが、電断時のDurabirityはどうなっているのか?
    • キャパシタを用いることで電断時に書き込みを終了させられるものもある。らしい。ということは、そうでないものもあるという感じか...
  • NoSQLには Eventual Consistency を保証しているものがあるが、maxの時間保証はあるか？あればどの程度か?
    • ちなみに、MongoDBはprimaryから読む限りに置いてはconsistentらしい。secondaryへのコピーに関しての時間保証はよくわからず *2

*1:トランザクションの基本 - Qiita

*2:https://www.mongodb.com/faq

Weekly Log 8 --- ただのLinkのDump ---

Weekly Log

ただのタブ整理を兼ねたリンクのdump。 とはいえ、今週どんな記事を読んだかをまとめるのは週の振り返りとしてちょうど良い気がする。 今週はk8sに加えて、DB・トランザクションやGoのコード生成関連を見ていた感じ。 5月病気味だったので復活していきたい。

K8s関連
DB関係
Golang
その他

Weekly Log 7 -- 雑録（OpenAPI, K8s Operator, OpenTelemetry） --

Weekly Log kubernetes

今週のトピックはこの辺り。

  • OpenAPI
  • Kubernetes Operator
    • Prometheus Operator
  • OpenTelemetry

週を追う毎に、記事とも呼べないような雑な記録になってしまっている...

Open API, Swagger

REST APIの仕様記述＆周辺ツール

この辺りの情報を参照

future-architect.github.io zenn.dev Swagger ではない OpenAPI Specification 3.0 による API サーバー開発

OpenAPIのコード生成について
  • SwaggerはOpenAPIの実装の一つ
    • 多分 Swagger←→OpenAPIはDocker←→Containerの関係に近そう
  • Swagger (Swagger Codegen)はSmartBear社が主導
  • コミュニティとSmartBear社の確執→分裂
    • Swagger CodegenのforkとしてOpenAPI Generatorの誕生
OpenAPIの仕様について
OpenAPIツール類
OpenAPIに関する感想
  • コミュニティと決裂したのはあくまでCodeGenerator関連
    • とはいえ swagger.io と openapis.orgそれぞれに仕様がある理由まで知らない。個人的には注意が必要。
  • VSCodeの拡張だけでもかなり書くのが楽になる
  • 自動テスト系は今後に期待

Kubernetes Operator

ユーザーに代わりステートフルなアプリケーションを自動で管理する Custom Contoroller のこと

らしい。

k8sの機能や仕組み(control loop等)を活用しつつ運用をコード化できる点が、ただのコード化と比べて嬉しい感じ。

つまるところ、ある種のデザインパターンで Operator patternという名前ができている。

運用能力に応じてレベル分けがある

  1. 基本インストール (Basic Install)
  2. 影響が無いアップグレード (Seamless Upgrade)
  3. フルライフサイクル (Full Lifecycle)
  4. 深い洞察 (Deep Insights)
  5. 自動操縦 (Auto Pilot)

Prometheus Operator

Prometheusの運用の実現だけではなく、k8sクラスタ自身のモニタリングの仕組みも持つ。

v1.16以降サポートらしく、今使いたい環境で使えない。悲しい。

感想

自分でOperatorを書くとk8s＆対象ソフトウェアに対する造形が深まりそう

OpenTelemetry

  • 今年2021年2月に仕様がv1.0に到達したOpenCensus&OpenTracingの後継
  • Java中心に参照実装も用意
  • 仕様の名前＆SDKの名前＆関連ツール総称

ymotongpoo.hatenablog.com

future-architect.github.io

トレーシングとメトリクス

OpenTelemetry(OpenCensus)ではトレーシングとメトリクスをサポートしているらしい。

  • トレーシング
  • メトリクス
    • 統計的情報（平均レイテンシ等）
実装
  • Jaeger, Zipkinは実質的に仕様(Open*)の実装っぽいかんじ
  • 収集後の分析基盤==backendとしてのJaeger, Zipkin?
  • OpenTelemetry自体にもクライアント参照実装がある
  • Backend==収集後の分析基盤はOpenTelemetryの範囲外
    • Zipkin, Jaeger,その他クラウドサービス等をBackend実装として使う
    • PrometheusもBackendの１つ
OpenTelemetryに関する感想
  • OpenTelemetryに対応したエージェント、収集分析基盤を個別に用意せず、Jaegerだけ使っても良さそう
  • 機能に不満があったら、Jaegerを共通仕様に沿う設定で使うようにしつつ、一部コンポーネントを置き換えると良さそう

Weekly Log 6 -- 書評: 雰囲気で使わずきちんと理解する！ 整理してOAuth2.0を使うためのチュートリアルガイド --

書評 Weekly Log

認証・認可について理解する必要にかられたので、先日あったDMMの７割引セールの際に仕入れたOAuthの本を読んだ。

booth.pm

タイトルに書評と書いているが、実質読書メモ

第１章 はじめに

OAuth2.0とは？

RFC6749を引用すると

OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可(Authorization) フレームワークである らしい。

すなわち、以下の４つを理解すればOAuth2.0が理解できると言っても過言ではない？ - サードパーティアプリ (画像編集アプリ等) - HTTPサービス (Google等) - 限定的なアクセス (一部写真の読み取り等） - 認可フレームワーク

なぜ必要か？

  • サードパーティアプリにパスワードを教える必要がない、教えたくない
    • 読み取りのみ許可したい
    • 流出を防ぎたい
    • HTTPサービス側からアクセス遮断するためにはパスワード変更しか無い

第２章：OAuthのロール

  • リソースオーナー
  • クライアント（サードパーティアプリ）
  • リソースサーバ(HTTPサービス)
  • 認可サーバ

リソースオーナー

Google とかのユーザ リソースを持つ人

クライアント

認証情報（クライアントID,クライアントシークレット）をセキュアに保存できるかでタイプ分け - コンフィデンシャルクライアント - サーバーサイドWEBアプリ等 - パブリッククライアント - ブラウザWEBアプリ、ネイティブアプリ等

リソースサーバ

Web APIでリソースを提供

認可サーバ

  • リソースオーナーの認証
  • オーナーからの同意を得る
  • アクセストークン発行

4つのロールの関係

  1. クライアントが認可サーバにリクエスト
  2. 認可サーバはリソースオーナーから同意をとる
  3. 認可サーバはクライアントにトークンを返す
  4. クライアントはトークンを使ってリソースサーバーにアクセス

第３章：OAuthのトークン

アクセストークン

スコープ

アクセス権コントロールの仕組み Googleは https://www.googleapis.com/auth/photoslibrary.readonly のようにhttpsのURL形式だが、決まったフォーマットは無い

有効期限

トークンの有効期限

リフレッシュトークン

トークンの再発行に利用される。

仕様として必須項目ではない

認可コード

「リソースオーナーがクライアントへの権限移譲に同意した証」 認可サーバが生成しクライアントに送る。 クライアントはこれをもとにアクセストークンを得る 仕様では10分以内の有効期限を推奨

第４章：OAuthのエンドポイント

認可エンドポイント

認可サーバのエンドポイント 認可コードを発行する

トークンエンドポイント

認可サーバのエンドポイント クライアントが認可コード等の情報を元にアクセス アクセストークンを発行する

リダイレクトエンドポイント（リダイレクトURI）

クライアントのエンドポイント クライアントは認可サーバのリダイレクトにより認可コードをURLのクエリ文字列として受け取る

第５章：OAuthのグラントタイプ

４種類のグラントタイプ（権限付与のタイプ）がある

  • 認可コードグラント
  • インプリシットグラント
  • クライアントクレデンシャルグラント
  • リソースオーナーパスワードクレデンシャルグラント

基本は全てのタイプでクライアントの事前登録が必要

クライアントの登録

クライアントはリソース（サーバ）提供組織に登録し、クライアントID、クライアントシークレットの発行を受ける。 *1 クライアントの登録する情報の内特に重要なのは、リダイレクトURI

認可コードグラント

最重要＆最複雑 PKCEとペアで原則推奨 コンフィデンシャルクライアントに最適*2

インプリシットグラント

パブリッククライアント向け 現在は非推奨

クライアントクレデンシャルグラント

クライアント（兼オーナー）＆認可サーバのみのやり取り

リソースオーナーパスワードクレデンシャルグラント

オーナーのユーザー名＆パスワードがクライアントを通して認可サーバに送られる

リフレッシュトークンによるアクセストークン再発行

認可コードグラント＋PKCE

パブリッククライアントで推奨 PKCE(Proof Key for Code Exchange)：ピクシー

第６章：チュートリアル

略

感想

ピクシーという単語は聞いたことがあった気がするけど、PKCEと書くことは初めて知った。

ともあれ、

OAuth完全に理解した！...気がするだけ

*1:これらの発行フォーマット、プロトコル等に規定は無い

*2:パブリッククライアントに使えないわけではない

Weekly Log 5 -- k8s meetup tokyoをまとめる#5〜#9 --

kubernetes Weekly Log

kubernetes meetup tokyoの動画を５回分ぐらい眺めたので軽くまとめる

#5 Kubernetes Meetup Tokyo #5 - connpass (2017/06/27)

[WIP] 運用しているサービスをKubernetes化するかどうか考える by @r_takaishi

  • ペパボのサービス運用をk8sに移すための検証
  • OpenStack+Rancherで構築
  • デプロイ早くなった

Using Kubernetes in Production by @koudaiii (wantedly)

  • k8sの細かい運用事例、歴史
  • 社内ツール色々

CoreOS Fest 2017 Recap by @hiyosi, @superbrothers

  • admission controller にwebhook追加している話
  • Draftが出た
  • Borgの話
  • Federated Cluster Selector

LT

個人的な学び

  • kubectl set image を初めて知った
  • Cluster Federationという概念を知った
  • Draftを知った
  • Controller Pattern&Informer
  • self-hosted k8s という概念
  • applyの差分はPATCH (gitの逆)
  • kops, kargo, kubeadm, kubespray

#6 Kubernetes Meetup Tokyo #6 - connpass (2017/08/08)

Running Workloads in Kubernetes by Janet Kuo (Google)

  • DeploymentとかStatefulSetとかの紹介
  • GKE, Minikubeの紹介
  • Helmの紹介

Kubernetes スケジューラーの詳細 by Ian Lewis (Google)

  • スケジューラもコントローラの１つと考えて良い
  • PredicatesとPriorities
    • Predicates: フィルタ, 除外
    • Priorities: フィルタで除外されなかったものからスコア計算, 最大のものに割当
      • まんべんなくスケジュールしたいorできるだけ少ないノードに詰めたいでは真逆
      • 複数の評価関数の重み付け平均
  • affinity, anti-affinity, taint become beta @v1.6
  • 自分でscheduler作成例（bash)
  • SIG Schedulingを参照

LT

*いろんなクラウドにKubernetesを簡単デプロイ by 門河 善也 (Kadokawa Yoshinari: Canonical, Senior Dedicated Services Engineer) * cluster-autoscalerの新機能「node group automatic discovery」の紹介 by mumoshu * GKEではStackDriverLoggingへどうやってログを送っているか? by takumi_yoshida_22 * 仮 Kubernetes 1.7 の概要 by tkusumi * Continuous Delivery on Kubernetes with Spinnaker by helix_kaz

個人的な学び

  • k8sのschedulerの知識が0から1に増えた

#7 Kubernetes Meetup Tokyo #7 - connpass (2017/10/12)

パブリック/プライベートクラウドでつかうKubernetes by @strsk (Cyber Agent)

Kubernetes with Prometheus by by tkusumi (Z Lab), kkohtaka (Z Lab)

LT

  • kubernetesの色々 by cyberblack28
  • Kubernetes でも Serverless したい！ by y_taka_23
  • Hardware LB で "type LoadBalancer" を使ってみた by SCHOfield
  • Securing Kubernetes clusters on AWS by mumoshu
  • githubを使って簡単にhelm repoを公開してみよう by everpeace

個人的な学び

  • Prometheusについての知見up
    • alert managerを初めて知った

#8 Kubernetes Meetup Tokyo #8 - connpass (2017/11/24)

Sail in the Cloud - An Introduction to Istio by Kamesh Sampath (Red Hat)

Cloud Foundry Container Runtimeで快適Kubernetes運用 by @jacopen (Pivotal)

  • BOSHというBorgインスパイアなk8s構築サービス

LT

  • Self-hosted Kubernetes を調べてみた by atoato88
  • 対話AI on Kubernetes by Chanmoro
  • Introduction of Kubernetes on AWS Workshop by riywo
  • Istio Ingressについて by mumoshu
  • CKAチャレンジ(挑戦中) by yupeji

感想、学び

  • mumoshさん、頻繁に発表していてすごい
  • self hostにはレベルがある

#9 Kubernetes Meetup Tokyo #9 - connpass (2018/01/12)

kubecon特集回 - Githubがk8sに移行した話のfollow up - Codefresh = spinaker + consourse CI + DockerHub - Open FaaS

Istio!!!

感想、学び

  • istio, envoy理解したい
  • istioの旨味
    • マイクロサービスでのカナリーテスト
    • zero trust network

Weekly Log 4 -- 書評: Kubernetes完全ガイド --

Weekly Log kubernetes 書評

Kubernetesの勉強のため、今月はこの本を読んだ

book.impress.co.jp

CyberAgentの青山さんが書かれたK8sの本の第二版だ。

全体の構成としては、

  • 導入
  • 環境構築
  • kubectlの解説
  • 各APIの解説
  • 各トピック（リソース、スケジューリング、監視、セキュリティ、etc)目線でのk8sおよび関連ソフトの解説

という感じだった（適当）

自分で手を動かさなくても良い程丁寧に例が載っていたり、図で丁寧に解説があったり、各プラットフォームの事例も合わせて紹介されていたり、 いろいろと工夫が凝らされていて良い本だった。

ただ、ボリュームが相当あったり、網羅的に、下手な言い方をすると辞書的に解説されていたため、時々眠くなった...

とはいえ、だからこそ、k8sでどんな事ができるのか&その概要を知る為にちょうど良かった気がする。 インフラ担当の人（ある程度インフラの概念がわかっている人）にとっては、適宜読み飛ばしつつ、全体を俯瞰する用に読むと、知識の高速道路として使うにはかなり優秀だと思った。

章立てもしっかりしていて、「こんな機能あったはずだけど、なんて言うんだっけ？」ってなったときに、パラパラめくって探して、あとは公式ドキュメントを見る。 みたいな感じで使うのに便利かなと思う。

ところでこの本、改訂版が出たのが去年の８月で、k8sのv1.18に対応しているけれど、v1.21となった今ではちょっと古く感じる （k8sのバージョン進行による影響の肌感覚が無いけれど..） 今の所、この本の内容の半分ぐらいしか頭に入っていないけど、５月には8割ぐらいは頭に入れて、最新のトピックを追い始めたいところ。

Weekly Log 3 -- k8s the hard wayとk8sのアーキテクチャと --

Weekly Log kubernetes

はじめに

k8sの勉強というと、「こんな機能がある」、「こういう使い方をする」ということを学んでいくべきなんだろうけど、正直面倒というか、丸暗記に近い感覚があってあんまり気が乗らない。

なので、k8sのアーキテクチャを中心に、必要に応じてk8sの機能も勉強していくことにした。 k8s the hard wayを起点に色々調べたのだけれど、記事にまとめる時間が無かったのでk8sのアーキテクチャについてメモ書きだけ残す。

k8sのコンポーネントの概要

公式ドキュメントの「Kubernetesのコンポーネント」より写真を引用してk8sを構築するコンポーネントを整理する。

https://d33wubrfki0l68.cloudfront.net/7016517375d10c702489167e704dcb99e570df85/7bb53/images/docs/components-of-kubernetes.png

コントロールプレーン

kube-api-server

etcd

  • 一貫性、高可用性を持ったキーバリューストア
  • Kubernetesの全てのクラスター情報の保存場所

kube-scheduller

  • Podにノードが割り当てられているか監視
  • Podを実行するノードを選択

kube-controller-manager

  • 各リソースを管理するコントローラを実行
  • 各コントローラはgoroutineとして実行される

cloud-controller-manager

ノード

kubelet

  • podの実行を保証
  • k8sが実行したコンテナのみ管理

kube-proxy

  • クラスタ内部、外部からPodへの通信を実現
  • OSのパケットフィルタリングが利用可能なら利用

コンテナランタイム

  • containerd等
  • コンテナの実行を管理

コントローラ

https://kubernetes.io/ja/docs/concepts/architecture/controller/

  • クラスタの状態監視
  • 期待される状態になるよう処理実行
  • 1つ以上のリソースを監視
  • 自分自身でアクション実行orAPIサーバに副作用付きメッセージを送信
  • 自作コントローラをPodとしてや外部で動作させることも可能