[Kubernetes] の [Pod] に関する情報を resource attributes として付与する [OpenTelemetry Collector] の processor[otlp] でテレメトリを送る場合、誰が送ったかは自己申告制なので Pod 自身が知り得ない情報を復元してあげる必要がある特にサイドカーとして [OpenTelemetry Collector] を用いない場合は resource attribute には基本的にはアプリケーションレベルの情報しか載ってこない

主に [Kubernetes] へのデプロイを前提とするラベルによるリソースの認識がうまく存在する世界こういうのものがない世界では設定の疎結合性とかはないやりたい設定の疎結合性

登場人物clilium-agent[eBPF] で L4 までのポリシー適用を行うL7 の処理は L4 ポリシーによって該当するトラフィックを cilium-proxy に投げるところまでやるcilium-proxy

概ねリモートホストで開発するという行為そのものをやめたほうがいいらしいですローカルで開発する場合でもセキュアストレージに頼らずにクレデンシャルを扱うにはどうしたらいいかという方向性自体は有用なのだが……基本戦略短命(<12h)なトークンを取得してキャッシュする可能ならメモリ上，短命なのでファイルに置くのでも可

[サーバネットワーク]は以下の機能を提供している複数のネットワーク上流の活用負荷分散・フェイルオーバー最適経路の構築自宅内ならトンネルを通らずにアクセスできる

[https://github.com/tosuke-lab/k8s GitHub - tosuke-lab/k8s: 無限大の魔法][k0s]シングルバイナリなディストリビューション[k0sctl]という(不安定なところもあるが)それなりに便利なインストールツールがあり，単体で[IaC]なデプロイが実現できる[CNIプラグイン] - [Cilium]

要求クラスタは HA に拡張可能なこと最初2ノードからとかなんで……もう何もわからん……いっぱいマシンがあってちょっと計算資源を無駄にしてもいいなら仮想化なんていらないのだ

[etcd] には他の [etcd] を使ってクラスタを構築する機能がある> [https://etcd.io/docs/v3.5/dev-guide/discovery_protocol/ Discovery service protocol | etcd]これだけだと鶏卵問題だが，パブリックなサービスが存在するのでこれを使って外部のオーケストレーションシステムに依存せずとも他のホストを発見してクラスタを構築できる

ほしい[Kubernetesクラスタ]を構築できる範囲のホスト抽象各ホストが [BGP] を喋ることを前提とした Pure L3 Network逆に言えば，[Kubernetes] とそのエコシステムを用いれば達成できる抽象化は不要VM やストレージの抽象化など

[2023-02-28][BGP Unnumbered で送出される RA]こんな発言をぐだぐだしていたらインフラ系っぽい人にフォローされたりしたただの学生だが？[My New Gear...]

目標可能な限りの冗長性冗長性を実現する技術は既存の環境に新しい機器を追加していく作業を簡単にするものであり，ドシドシ拡大したいという気持ち冗長性を確保するための技術の導入を阻まないようにする例

[Kubernetes] においては [cert-manager] などで Secret の形で発行した証明書を標準の [Ingress] リソースなどの [TLS] に関する部分に設定することで [TLS] を使った通信が可能になるしかしこれを単純に使うにはいくつか問題があるSecret リソースは名前空間でローカルであるため，ある名前空間でワイルドカード証明書を発行したとしてもその証明書は他の名前空間では使うことができない

[Jsonnet]で[Kubernetes]のマニフェストを書く話[JSON]か……ってなるが思ったより表現力が高いよく考えると[YAML]のフォーマットって流派があって微妙……[Argo CD]でデプロイするときの情報もある[https://zenn.dev/atodekangae/articles/435d4d4f3ef55d Jsonnet で Kubernetes マニフェストを快適に書く]

[https://zenn.dev/taisho6339/books/fc6facfb640d242dc7ec Kubernetesネットワーク 徹底解説][Kubernetes]のネットワークについて[flannel]同一ノード内ならBridgeでルーティングノード間は[VXLAN]で通信

[Kubernetes]における[Observability]について[Observability](aka. [可観測性])とは何か5つの指標についてMetricsLogs

[Kubernetes]における[Secret]の管理方法について[kubesec]は[kustomize]との相性が最悪[sealed-secrets]はマルチクラスタで鍵の不整合が起きて使えない[Berglas]([Google Secret Manager])は名前空間の概念を持たないので[Kubernetes]と思想が衝突する[External Secrets]はまあ動く

[Pod]が各ノードに1つあるという状態を定義する[Kubernetes]のリソース何に使うのかわからない……[tosuke.icon]

[ReplicaSet]を管理して[Rolling Update]やロールバックを実現する[Kubernetes]のリソース

[Kubernetes]における計算リソースの最小単位複数のコンテナを持てる！[Sidecarパターン]や[Ambassadorパターン]、[Adapterパターン]などのパターンがある

[Pod]がある一定数個デプロイされている状態を定義する[Kubernetes]のリソース

[GitOps]で[Kubernetes]の[Secret]を扱えるようにするために、公開鍵暗号を使って暗号化したものをPushするSecretには値を[base64]したものが入ってるだけだから、リポジトリには上げられないConfigから値を分離することが責務なんだろうなこれだけ別にApplyするGit外で管理する責任を1つの鍵に押し付けているとも言える