Kubernetesのマルチテナントの現状を整理する - TECHSTEP
はじめに 本記事では、Kubernetesで実現するマルチテナントについて、2020年9月時点での現状と、将来的に利用できるであろう機能の紹介をいたします。各機能についての詳細は、参考ドキュメント等を参照していただければと思います。 本記事の要点 マルチテナントは単一のクラスター上に複数のテナントを共存させることを指す。 Kubernetesにはマルチテナントを実現するための機能が備わっている。 アクセスコントロール：RBAC セキュリティ：Namespace / Network Policy / Pod Security Policy リソースの隔離：ResourceQuota / LimitRange / Affinity / Taintなど Kubernetesのマルチテナント機能は、SIGを中心として機能開発が進められている。 Benchmarks Tenant Controlle
【全人類へ】お前らはスペルミスが多すぎるッッ！！絶対に入れて欲しい拡張機能！【VisualStudioCode】 - Qiita
【全人類へ】お前らはスペルミスが多すぎるッッ！！絶対に入れて欲しい拡張機能！【VisualStudioCode】HTMLJavaScriptフロントエンドVSCodeVisualStudioCode みなさん、おはようございます！ @f0lstです！ さてさて、いきなりですが。 よく聞くんだ… お前らはスペルミスが多すぎるッッ！！！！！ スペルミスしすぎじゃないかッッ!?!?!?!? と言っておりますが、僕自身もスペルミスとっても多いです そんな我らに救世主を 我は救世主 「Code Spell Checker」 だ... これこそが、全人類に使ってほしいVSCodeのExtention、「Code Spell Checker」です！ これを使えば、タイポの悩みから解放されます それぞれの世界線を見てみよう まず、Code Spell Checkerがない世界線 「さてさて、いつも通りコー
Kubernetes の Probe の仕組みと考慮点
Kubernetes 1.26 時点の話で、以降のマイナーバージョンで改善されている可能性があります。 Kubernetes には、ワークロードの正常性を確認するための Probe という仕組みがあり、Liveness / Readiness / Startup Probe が用意されています。kubelet (Kubernetes のノード上で動作するエージェント) は、ワークロードに対して TCP Socket / HTTP GET / gRPC / Exec の中から指定されたチェックを定期的に実行します。 それぞれの Probe の特性を理解して使い分けないとサービスに影響することがあります。本記事では、Probe の仕組みと考慮すべき点について紹介します。 Probe の仕組み Exec と TCP Socket / HTTP GET / gRPC の Probe の仕組みは異な
ローカル開発環境準備 - 自動化ツール(Skaffold) | 豆蔵デベロッパーサイト
前回は、minikubeを使ってローカル環境内でコンテナアプリケーションを実行する環境を整えました。 しかし、サンプルアプリのデプロイを通して、ソースコードに加えて、コンテナイメージのビルドやKubernetesマニフェストの反映等、手順が煩雑だと感じられた方も多かったのではないでしょうか？ コンテナ以前のアプリ開発だと、任意のIDEを利用してソースコードを記述し、IDEまたはコマンドからそのままローカル環境で実行・確認していた方が多いと思います。 Kubernetesに載せるためには、追加手順としてコンテナのビルドやマニフェスト反映が必要となり、これを手動でやっていては間違いなく開発効率が悪くなることでしょう。 今回はこれを解決するために、Google社で開発・運用しているKubernetes向けの自動化ツールのSkaffoldを導入し、この面倒な手順を自動化してしまいましょう。 なお、
ローカル開発環境準備 - 実行環境(minikube) | 豆蔵デベロッパーサイト
それではここからはアプリケーションの開発編に入っていきましょう。 チームでKubernetesで動作するアプリケーションを開発する場合に、どうやって各開発者がコンテナ環境で動作するアプリケーションを実装・テストすればよいでしょうか？ クラウド上に各個人のクラスタ環境を準備するのが理想的ですが、コスト的に難しいというのが一般的かと思います。 そのような場合は、コンテナ以前の開発ように各ローカルマシンでアプリケーションプロセスを起動して動作確認を行い、実際のクラスタ環境での確認は結合試験等で実施することになるでしょう。 これでもいいのですが[1]、トライ＆エラーでクイックフィードバックが得られるローカル環境で、コンテナ内のアプリの振る舞いやKubernetesのリソース(DeploymentやService等)の定義を確認できる方が断然効率的です。 ここではローカル環境でスモールバージョンのK
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
