以前書いた"コンテナストレージの基礎理解"の改変版です。

はじめに このエントリーは、Google Cloudのエンジニアである@ahmetb氏のブログ記事を日本語訳したものです。 以下のツイートを見つけて、良さそうだったので翻訳の許可をいただきました。 Mastering KUBECONFIG article has been the top read page on my blog over the past year. 🤷🏼‍♂️ Not sure what to make of this. https://t.co/t4pWwOpgQW— Ahmet Alp Balkan (@ahmetb) March 11, 2021 KUBECONFIGのすべて kubectlが動作するその裏側には、kubeconfigというファイルの存在があります。このファイルは一般的には$HOME/.kube/configに存在しています。私がkubectx

Azure Kubernetes Service (AKS) でホストされるアプリケーションをリリースした後は、Day-2 Operations を準備します。 Day-2 Operations には、トリアージ、デプロイ済み資産の継続的メンテナンス、アップグレードのロールアウト、トラブルシューティングなどが含まれます。 Day-2 Operations は以下に役立ちます。 サービス レベル アグリーメント (SLA) またはサービス レベル目標 (SLO) の要件を維持する。 カスタマー サポート リクエストのトラブルシューティングを行う。 最新のプラットフォーム機能とセキュリティ更新プログラムを最新の状態に維持する。 将来の成長に備えて計画する。 前提条件 Day-2 Operations ガイドにおいては、運用クラスターの例として Azure Kubernetes Service

Red HatでOpenShiftのサポートエンジニアをしているDaein（デイン）です。 OpenShift 4.5(Kubernetes 1.18)からstartupProbeがBeta機能としてデフォルトで利用できるようになりましたのでどのような機能であるか確認していきます。 関連リリースノートは以下のリンクです。 github.com Probesとは これまでlivenessProbeとreadinessProbeは、安定的なサービスが提供できるようにコンテナの起動状態を定期的にチェックし、正しく起動できなくなったコンテナを再起動させたり、外部からのアクセスを遮断させたりする機能を提供していました。 詳しい内容や詳細は次のリンク先をご参照ください。 docs.openshift.com kubernetes.io 今回は新しく追加されたstartupProbeという起動フェーズを

はじめに Kubernetes 1.20 の CHANGELOG から SIG Cluster Lifecycle の取り組みについてにピックアップしました。前から使用が微妙と思われていた "node-role.kubernetes.io/master" ラベルおよび "node-role.kubernetes.io/master:NoSchedule" taints の削除に動き出したようです。 主な変更点 (What's New) kubeadm の非推奨になったフラグが削除されました kubeadmは、このリリースで多くの非推奨と非推奨機能の削除を行います。 詳細については、「重大なアップグレードに関する警告」および「種々の変更/廃止予定」セクションを参照してください。 既知の問題 (Known Issues) なし。 重大なアップグレードに関する警告 (Urgent Upgrade

はじめに 利用した環境 cgroup の階層構造 例：CPU やメモリの制限 例：PID 数の制限 例：CPU コアの排他的割り当て まとめ 執筆者 : 山下雅喜 はじめに cgroup とは、Linux カーネルの機能の1つであり、プロセスやスレッドが利用するリソースの制限や分離を行うための機能です。 cgroup は名前空間の機能と共に、Linux コンテナの根幹を成す技術の1つでもあります。 Kubernetes において、名前空間は PID 名前空間、ネットワーク名前空間、マウント名前空間などで利用者の目に触れやすい存在ではありますが、cgroup は相対的に目に付きにくいもののように感じています。 そこで今回は、Kubernetes のいくつかの機能を例に挙げ、cgroup がどう利用されているか見ていきます。 利用した環境 利用したソフトウェアおよびバージョンは次の通りです。

Kubernetes 1.20から始まるDockerランタイムの非推奨化に備えよう！我々が知っておくべきこと・すべきこと はじめに Kubernetesの次のマイナーバージョン1.20が、2020年12月8日にリリースされました。今回のリリースではGraceful Node Shutdownの追加やkubectl debugのBeta昇格など、運用に嬉しいさまざまな機能のアップデートがあります。その中でも、12月初頭にGitHubや公式Slack、Twitterなどを賑わせたのがDockershimの非推奨化でした。公式のリリースノートには以下のように書かれています。 Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a modu

2018.2.2 [Kubnernetes] kubelet の runtime を docker から cri-o に置き換える みなさんこんにちは。 アドテク本部の makocchi です。 kubernetes で使われている container の runtime にはみなさん何をお使いでしょうか？ ほぼ全ての人が docker と答えると思います。実際 Google Kubernetes Engine(GKE) も runtime には docker が使われています。(2018年01月現在) しかし kubernetes はこの container の runtime を自由に選択することができます。 kubernetes と container runtime の間は CRI(Container Runtime Interface) を通して行われます。 つまり CRI に対

追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね！！！」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合

自宅の検証用マシン (Deskmini A300) に ESXi を入れて検証環境として利用しています。 最近はそこへ k8s クラスタを構築して色々試しているのですが、クラスタ内に立ち上げたサービスへは IP アドレスでアクセスしていました。 IP アドレスでアクセスするのはとても面倒だったのですが、やっと k8s で動かしているサービスに FQDN で繋がるようになったので投稿します。 システム構成図 使用するプロダクト 構築 DNS サーバ (CoreDNS & etcd) 構築 コンテナネットワーク CoreDNS etcd 動作確認 MetalLB ExternalDNS デプロイ アノテーション付与 動作確認 おわりに システム構成図 完成後のシステム構成図になります。 （構成図描くの下手で分かりにくいと思います…） 見てもらって分かる通り、LAN 用の DNS サーバを VM

Kubernetesとその関連コードのコードリーディングをする上で知っておくと良さそうなことについて知ってる範囲で雑にまとめてみました 前提知識前提として最低限Kubernetesをある程度触っていて KubernetesはPodとかのリソースと呼ばれるものでコンテナだったりロードバランサーとかを管理するようになっていて実際にDeploymentでコンテナを立ててService/Ingressでコンテナで立てたアプリケーションを外部公開できてコンテナはPodという単位でコンテナをグループ化して同一Nodeで実行されるということを知っているくらいがわかっていればまぁ十分なんじゃないかとは思います あとはKubernetesはGoで書かれているので Goの基礎知識とVSCodeやGolandなどGoのコードを読む際に宣言にジャンプできるようなエディタくらいがあると良いと思います Kuberne

Kubernetes3 Advent Calendar 201811日目の記事です。 自分がhelm Chartのテンプレートを書く前に知っておけば良かったなーというポイントを紹介します。 大体、The Chart Template Developer’s Guideに書いてあるので、ここをちゃんと読んでから始めれば良いのですが... 1. 複数環境ある場合は--valuesオプションで変数を環境別に指定するのがよさそう このスライドのように環境別に変数ファイルを使うのがよさそうな感じです。(同社なので、マネしてます...) 2. --setオプションは--valuesで指定したファイルを上書きする tagの指定だけ上書きする時などに使っています。 3. - は難しい ifの-は前の空白と改行を削除してくれるのですが、elseだけ表示したい場合にコントロールが難しいです... 下のように書

SREのたっち(@TatchNicolas)です。 JX通信社では、月に一度「WinSession」というリリースした機能や検証したリリースについて開発チーム全体へ発表する機会を設けています。今回は自分が前回社内に紹介した「パパッと便利APIを作って5分でお手軽＆セキュアにデプロイする」方法について書きます。 TL; DR; Istio/cert-manager/Auth0を使って、任意のコンテナを認証つきで5分でデプロイできる仕組みを作った 設定はアプリケーションごとに独立し、中央集権的なリポジトリに依存しない*1 きっかけ プロダクト間で共通のAPIを認証付きでパパッと作りたいこと、よくありますよね？ でも、アプリケーションに毎回認証のための仕組みを組み込むのは骨が折れます。アプリケーションはあくまで、アプリケーションの関心ごとに集中させたい。すると、サイドカーコンテナを使って責務を分

2021/03/01　追記 記載していたリポジトリにあるマニフェスト系があまりに不親切だったので、ちゃんとまとめてみました。 後日、もうちょっとちゃんと記事書こうとは思いますが、大体はREADMEにあるので読んでみてください。 sock-shopをベースにObservability（Prometheus, Loki, Istio(Jaeger, Kiali)）とProgressive Delivery＆自動負荷試験スタック（Flagger, Jmeter, influxdb）をHelmとKustomizeで詰め込みました。 今回はちゃんと誰もが入れれるようにがんばってみたので、どうぞ。 github.com この内容でCloudNativeDaysOnline2021に登壇することにしています。 event.cloudnativedays.jp 後、随分前ではありますが、本投稿に関連してK

概要 custom metrics による HPAについて調べる過程で Operator や Adapter に関する知見を得ましたので共有します。 CloudNative Days Kansai 2019 MeetupでLTした際のスライドもご参照ください。 以下について記載しています。 Pod Autoscaler VPAとHPA CPU使用率によるHPA custom metricsによるHPA Operatorとは Adapterとは Pod Autoscaler VPAとHPAがあります。 VPA( Vertical Pod Autoscaler ) resources requestsを増減してくれます。 HPA( Horizontal Pod Autoscaler ) pod数を増減してくれます。 本記事はHPAに関するお話です。 CPU使用率によるHPA 公式ドキュメント(

インポート～情報蓄積 ・他のツールから簡単にインポート ・みんなでリアルタイム共同編集 ・編集履歴の確認とロールバック ・下書きレビューでワークフロー化 ・Markdown、リッチテキストエディタ、PlantUML ・Excel、CSV、スプレッドシートをコピー＆ペーストで表作成 ・画像、動画をコピー＆ペーストで貼り付け ・よく使う情報をテンプレート化 構造化～活用 ・グループでアクセスコントロール、フォルダで構造化 ・複数条件に対応した高度な検索 ・プレゼンテーション機能 ・記事を外部共有 ・いいね！でレスポンス、コメントで議論 ・迅速なチャットサポート ・API、Webhook、Zapierなど外部ツール連携 高度なセキュリティ ・SAML 2.0認証 SSO（Google Workspace、OneLogin、Azure Active Directory、Okta、GMOトラスト・ロ