オンプレミスからクラウドへの移行をはじめ、ハイブリッドクラウド環境をシームレスに保護しながら、クラウドの利点を実現します。 詳しくはこちら
本記事は、TechFeed Experts Night#28 〜 コンテナ技術最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 このセッションでは、Kubernetesの仕組みやそもそも論みたいなところから、デモをまじえてお話ししていきます。 手元に立てたクラスタのデモをお見せします。まず、いくつかコマンドを打つとエラーになります。Kubernetesを触ったことのある方はお気付きだと思いますが、このエラーの出方は非常に奇妙です。なぜなら、PodやDeploymentが何も登録されていない場合であれば、「No resources found(リソースが見つからない)」と言ってくるはずだからです。今回のエラーメッセージは「サーバにそんなリソ
「@IT Cloud Native Week 2024冬」の基調講演に、NTTデータグループ テクニカルリード 小林隆浩氏が登壇。「今から学ぼう!クラウドネイティブなデータベースの世界」と題して、クラウドネイティブ環境でデータベースを選択する上での基礎知識や、現在のトレンドと今後の展望を解説した。 DBaaSの利用率が圧倒的に高く、コンテナ環境でのDBはまだ少ない状況 クラウドネイティブが浸透する中、データベースをクラウドで提供するDBaaS(Database as a Service)の在り方は絶えず変化している。小林氏は「私は普段から『データベースをKubernetesで動かしましょう』という話をします。今日はその辺りの話から始め、データベースのマルチクラウド展開とはどのようなものなのか、今後どうなるのかといった話までたどり着きたい」と切り出した。 小林氏は、「Oracle Datab
LINEヤフーはDB自動チューニング術を紹介――「KubeCon」で気になった最新のKubernetes×データベース運用ノウハウ:「KubeCon+CloudNativeCon North America 2023」レポート 「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介していきます。今回は「KubeCon+CloudNativeCon North America 2023」で気になった内容をお届けします。 「クラウドネイティブ」という言葉がなじんだ今、市場に登場した新たなデータベースやデータベースを支えるプラットフォームにまつわる情報を紹介する本連載。前回はNewSQLの一つである「YugabyteDB」のユーザーによるラウンドテーブルの様子をお届けしました。国内市場でもクラウドネイティブな新しい
プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術 2024年3月5日 株式会社サイバーエージェント インフラエンジニア 青山真也 (Masaya Aoyama) 2016年、新卒でサイバーエージェントに入社。OpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームをゼロから構築し、国内カンファレンスでのKeynoteに登壇。著書に『Kubernetes完全ガイド』『Kubernetesの知識地図』『みんなのDocker/Kubernetes』。現在はKubernetesやOpenStackなどOSSへのコントリビュート活動をはじめ、CloudNative Days Tokyo Co-chair、CNCF Japan ChapterのOrganizer、Kubernetes Meetup TokyoのOrgani
KEELチームの相原です。 今回はeBPFを利用してKubernetesクラスタの可観測性の隙間を埋めている話です。 前回のエントリではLLMにうつつを抜かしていたので本業(?)の話をしようと思います。 www.lifull.blog LIFULLの可観測性の現在地 eBPFとは 可観測性の隙間 NAT Loopback eBPFを実行するには BPF CO-RE libbpf-rsを利用したNAT Loopbackの検知 1. (ユーザ空間) コマンドライン引数として受け取ったDNSをTTLごとに名前解決してIPアドレスを取得する 2. (ユーザ空間) IPアドレスに変化がある度にカーネル空間で動くBPFプログラムにそのIPアドレスのリストを渡す 3. (カーネル空間) Kprobesで tcp_v4_connect/tcp_v6_connect にフックを仕込む 4. (カーネル空間)
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Istioのサイドカーメッシュを題材にしたEnvoyの設定の抽象化について 様々なサービスメッシュツール (特に、Istio、Consul、Cilium、など) でも流用できるEnvoyの知識について この記事から得られる知識 01. はじめに 02. 様々なリソースによるEnvoy設定の抽象化 サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 03. istio-proxyコンテナによるHTTPS処理 Istioコントロールプレーンの仕組み サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 04. EnvoyによるHTTPS処理 Envoyの設定の種類 フィルター フィルターの一覧 フィルターチェーンの仕
はじめに Kubernetes は v1.25 で cgroup v2 サポートを GA しており、その後に cgroup v2 に関連する機能が追加されています。しかしまだ多くのディストリビューションで Kubernetes がデフォルトで cgroup v2 を使用しない設定のため、実際に利用している方は多くないと思います。PFN では2022年12月に Kubernetes バージョンを v1.25 にアップグレードするのと同じタイミングで cgroup v2 に切り替えています。 このエントリでは Kubernetes の cgroup v2 に関する機能である MemoryQoS フィーチャゲートと memory.oom.group の2つについて、機能概要と課題を共有します。なお、Kubernetes v1.28 時点での情報です。 そもそもの cgroup v2 について そ
第1回目の今回は、Podのリソース割り当ての推奨値を提案する「KRR(Kubernetes Resource Recommender)」について紹介します。 はじめに こんにちは。3-shakeで技術顧問を勤めている青山真也(@amsy810)です。 3-shakeでは、CloudNative技術などを用いたSREの推進などを行っており、Kubernetesに関連した各種ソフトウェアへのキャッチアップなども積極的に行っています。 そこで、本連載では「OSS Insight」で公開されているソフトウェアや、最近話題になっているが、まだ詳細についてまとめられていないようなKubernetesに関連するツール・ソフトウェアを検証し、3-shakeのメンバーで紹介していきます。 第1回の今回は、Podのリソース割り当ての推奨値を提案する「KRR(Kubernetes Resource Recomm
cert-managerとは kubernetesクラスタ上でSSL/TLS証明書をシンプルに扱うためのツールです。 証明書の取得・更新・利用が簡単になります。 公式ドキュメント この記事の内容 この記事では、cert-managerを利用していくにあたり、最低限おさえておきたい「証明書発行・利用の流れ」と、「登場人物」だけを簡単にまとめます。 証明書まわりは分かりづらいし、事故ったら大変なことになるので、あまり触りたくない箇所かもしれませんが、基礎知識を知っておくことで最初の足がかりになると思います。 cert-manager v1.6.1での話をしていきます。 また、Let's EncryptをIssuerとした流れを説明しますので、他のIssuer Typeでは内容が異なる箇所があります。 証明書発行・利用の簡単な流れ まずざっくりとした流れを書いておきます。 実際のインストール方法
はじめに 本ドキュメントでは、Kubernetes 1.27.0のCHANGELOGをベースにSIG Storageに関する機能について紹介します。 がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。 アップグレード前に絶対に確認が必要な変更点 (Urgent Upgrade Notes) SIG-Storageに関連するものはなし Changes by Kind 非推奨 (Deprecation) SIG-Storageに関連するものはなし APIの変更 (API Change) seccomp profile defaulting がGAになりました。 kubeletの--seccomp-defaultフラグ又はkubeletのコンフィグのseccompDefaultをtrueに設定することで、RuntimeDefault seccomp profileがノード上のP
1行で カジュアルな気持ちでk8sの翻訳に関わり始めたよ。 背景 YAPC KYOTO 2023はYouTubeで視聴していて、Linux Conferenceの主催側立場だったりした頃を思い出したり、Debian ConferenceやRuby会議も楽しかったなーなどと感慨にふけっていた(今年のRuby会議はちょっと行きたいなと思ったんだけど、業務とつなげるのが現状では難しそうなのもあって見送り)。 yapcjapan.org 発表はどれも印象深かったのだけれども、最後のLTで@nasa9084さんの「Kubernetesの翻訳協力者募集!」を聞いて「Kubernetes使える人は英語で特段問題なさそうだなぁ」と感想を呟いたところ、@nasa9084さんに拾っていただいて反応をもらった。 speakerdeck.com そもそも翻訳をできる人は日本語のドキュメントを必要としてないので、コ
Kubernetes: cgroup v2 使用時に "failed to create fsnotify watcher: too many open files" エラーが発生する問題の対策cgroupskubernetescontainerdcgroup-v2 はじめに Kubernetes 1.25 で cgroup v2 が GA しました。Kubernetes で cgroup v2 に移行するとメモリ QoS が導入され、Pod のメモリ使用量が増加した際の安定性が向上するメリットがあります1。そこでクラスタを Kubernetes 1.25 にアップグレードする際に一緒に cgroup v2 に移行したのですが、移行後に kubectl logs -f コマンドやノードのホスト上で journalctl -f を実行した際に次のエラーが発生するようになりました。
ただ、サーチリストがこうなっているのは利便性のためだけではなく、もっと切実な理由があります。 サーチリストとndots DNSの一般的な名前解決のルールとして、こんな風に覚えている方もいるかもしれません。 名前にピリオドが含まれていたら、FQDNとみなしてサーチリストを参照せずに名前解決を行う 名前にピリオドが含まれていなければ、サーチリストのドメインを末尾に連結して名前解決する 例えば、こんな具合です。 $ ping myhost # ピリオドが含まれていないため、myhost.example.comが名前解決される PING myhost.example.com (192.168.0.1) 56(84) バイトのデータ 64 バイト応答 送信元 myhost.example.com (192.168.0.1): icmp_seq=1 ttl=57 時間=12.4ミリ秒 $ ping w
kubernetesをGCPやAWS上で動かすとき、実務でぶち当たった壁、考えないといけないポイントをまとめていきます。 AWSのマネージドで動かすか? k8sの中で動かすか問題 証明書関連 どこでSSL終端を行うのか?k8s-cluster外でSSL終端するのか、しないのか?を考える必要がある。さらにその証明書を得るときに期間が切れたときに自動で証明書を発行するのかいなかなどもある。 シークレット関連 通常、k8sでsecrets.yamlファイルを定義した場合、Secretのvalueはbase64で、エンコードされるだけで、エンコードされた文字列を知れば、簡単にデコードできてしまう。そのため、secretsを以下のサービスを使用して外部に置いておいて、必要な時に動的に取得するといったシークレット管理の仕方が存在する。 external-secrets-operator(ESO) SS
ChatGPTにKubernetesのアラート対応を教えてもらう。監視ツールとChatGPTをつなげる「Kubernetes ChatGPT Bot」登場 オープンソースで開発されているKubernetesのモニタリングツール「Robusta」の開発者Natan Yellin氏は、AIを利用して人間とチャットで会話をする能力を備える「ChatGPT」をRobustaと統合した「Kubernetes ChatGPT Bot」を公開しました。 Kubernetes ChatGPT Botは、発生したアラートの内容を自動的に受け取り、対処方法をAIがチャットで教えてくれるというものです。Natan Yellin氏は「もう、一人でやみくもにアラートの対応をしなくて済む。インターネットがあなたの味方だ」(No more solving alerts alone in the darkness - t
Kubesharkとは 図は公式 より抜粋 KubesharkはKubernetesのための観測性・監視ツールで、マイクロサービスの動的解析、異常の検出などを実現するツールです。 Wireshark、BPF Compiler Collection(BCC)ツールなどを組み合わせた、Kubernetesを意識したものとお考えください...と説明されています。 Kubesharkは、クラスタ内の一部またはすべてのTCPトラフィックをスニッフィングし、PCAPファイルに記録し、HTTP1.0, HTTP1.1, HTTP2, AMQP, Apache Kafka, Redisなどのアプリケーション層プロトコルを分析できるとのことです。 今回はHTTPに絞って実際に環境を動かしてみて、トラフィックを覗いてみたいと思います。 Kuberentesクラスターの用意 まず、Kuberentesクラスター
マルチテナントKubernetes環境のKubernetes External Secrets が非推奨になるので External Secrets Operatorへ移行した話
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く