アルパカでもわかる安全なPodの終了 - 実験編
これはなに この記事はアルパカでもわかる安全なPodの終了の続編です。 前回は、Podの終了時の動作をKubernetesの各種コンポーネントの仕組みを踏まえつつ考察しました。 Deploymentのローリングアップデートを行うとPodの再起動を伴うことになりますが、このときリクエストを欠損なく処理するために、以下2つの対策が有効であることが分かりました。 preStopフックでのスリープ アプリケーションのGraceful Shutdown この記事では、Deploymentのローリングアップデートをオンラインで実際に行い、上記対策が本当に有効かどうかを確かめていきます。 📘【note】 この記事はKubernetes2 Advent Calendar 2020の18日目です。 昨日は@south37さんの手を動かして学ぶコンテナ標準 - Container Runtime 編でした。
アーキテクチャから読み解くKubernetes～Controllerの仕組み～
クラウドで使うコンテナというと、AWSのAmazon ECS、Google Cloud Runなどがある。今回はコンテナオーケストレーションのKubernetesのアーキテクチャについて、スリーシェイク bells17氏が解説する。KubernetesはもともとGoogleが内部で運用していたコンテナ基盤のBorgをベースとしており、Cloud Native Computing Foundation（CNCF）に寄贈されたものだ。認知度からも分かるように、成熟度レベルは「GRADUATED」で成熟が進んだものとなっている。 KubernetesのコアとなるControllerとは？ コンテナオーケストレーションツールとして有名なKubernetes。代表的な特徴を挙げるとサービスディスカバリとロードバランシングがある。Serviceリソースを定義することで、多数起動されているコンテナに接続
昼夜で稼働台数を調整できるCronHPA Operatorを作りました！｜Daisuke Taniwaki
CronHPAという昼夜のような時間帯で稼働台数やメトリクスを調整できるKubernetes Operatorを作ったので紹介します。 以下のようなYAMLの記述で最低稼働Pod数4、最大稼働数10でPod全体の平均CPUが50%以下になるように自動でPod数を調整してくれます。 apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: nginx spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx minReplicas: 4 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization
モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog
こんにちは、プラットフォームエンジニアリング部門コンテナ基盤グループの岡田です。 当社ではECサイトの裏側で利用されているモノリシックなAPIをコンテナ化し、Elastic Kubernetes Service (EKS) に移行しました。 移行直後は下記のようにトラブルに見舞われましたが、現状安定した運用ができています。 EKSコンテナ移行のトラブル事例：推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog EKSコンテナ移行のトラブル事例：FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog 今回はトラブル事例ではなく活用事例になりますが、アプリケーションリリース起因でのトラブル影響を減らすため、コンテナ化したAPIに対してカナリアリリース導入を行いました。そのため、導入に際して生じたConfigやSecret周りの課題
AIにプログラミング作業を奪われている - k0kubun's blog
せっかく10年以上かけて学んだプログラミングだが、人間がコード書くよりChatGPTにやらせた方が早いなということが度々あり、だんだん自分でプログラミングをやる時間が減ってきた。AIにコードを書かせてそれをGitHubにコピペして残りの時間は遊んでるだけで成果が出てお給料ももらえる日は近いし、段々会社もそのことがわかってきて失職する日も近い。 残念ながら現時点では全ての仕事がAIで上手くいくわけではないが、どういう時に使えるかを知っておくと楽をしやすくなるので、僕がどう使っているかをまとめておく。 失職できるケース 簡単なスクリプトを高速に書かせる 僕はRubyが全ての言語の中で一番慣れており、StackOverflowやドキュメントをほぼ見ずに大抵のプログラムを書き切れるため、Rubyを書いている時がプログラマとして一番生産性が高いのだが、それでも最近AIにRubyを書かせたことがあった
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
Kubernetesに対する理解を高めてKubernetesの「わからない」を減らそう
Kubernetes Novice Tokyo #29 で発表したLT資料です イベントURL: https://k8s-novice-jp.connpass.com/event/300438/ 動画URL: https://www.youtube.com/watch?v=WZHDlB8P9_4 参考資料: https://github.com/kubernetes/kubernetes/tree/v1.28.4 https://github.com/coredns/coredns/tree/v1.11.1 https://github.com/coredns/example https://github.com/coredns/coredns/blob/v1.11.1/plugin/kubernetes/README.md https://github.com/kubernetes/dn
MercariにおけるKubernetesのリソース最適化のこれまでとこれから
Kubernetes Meetup Tokyo #57 アーカイブもあります: https://www.youtube.com/watch?v=DczWeNL-4-A
Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」、本番環境で使えるレベルに到達したとしてCNCFの卒業プロジェクトに
Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」、本番環境で使えるレベルに到達したとしてCNCFの卒業プロジェクトに Cloud Native Computing Foundation（CNCF）は、Kubernetes上でイベントドリブンなオートスケーリングを提供する「KEDA」（Kubernetes Event-driven Autoscaling）が、本番環境に十分使えるレベルに到達したとして、インキュベーションプログラムから卒業するプロジェクトになったと発表しました（CNCFの発表、KEDAの発表）。 [NEWS] Announcing the Graduation of #Kubernetes autoscaler #KEDA! https://t.co/qpSz3zyad5 pic.twitter.com/ETddPp8ENF — CNCF (
EKSコンテナ移行のトラブル事例：推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog
こんにちは、モノタロウの SRE グループ・コンテナ化推進チームの田中です。 現在、私たちはシステムモダナイゼーションのプロジェクトの一環として、200以上のエンドポイントを持つモノリスのバックエンド API を EC2 上から Kubernetes マネージドサービスの EKS（Elastic Kubernetes Service）に移行しています。ノードは Fargate を使用し、監視には Datadog と Sentry を導入しています。 今回、EC2 に流れているリクエストを全て EKS に振り分けを行おうとしておりました。その際に外部（DB、 サービス）への疎通ができないといった内容の Sentry のエラーが大量に発生し、切り戻しをせざるを得ない状況に陥ったのです。エラー内容を詳しくみたところ名前解決に関するものであり、今回私たちは CoreDNS の設定を行うことで解決し
EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog
こんにちは、SREグループの岡田です。 モノタロウではモノタロウのクラウドネイティブ化の取り組みについて - MonotaRO Tech Blog にも記載されているようにシステムのモダナイズに取り組んでおり、その一環でEKSのPoCそして実際にECサイトの裏側のAPIを対象にコンテナ化に取り組みました。 この記事では移行時に起こったトラブルとハマったポイントの1事例をご紹介します。 前提 起こったトラブル トラブルシュート 1. 問題の整理と仮説 2. 検証 検証1.Podのステータスがterminate状態になってから削除されるまでの時間を変えてみる。 検証2.Pod Readiness Gateを試す。 検証3. ALBのDeregistration delay（登録解除までの待機時間）を短くしてみる。 分かった事 ALBを含めたPod入れ替え時の挙動 EKSにおけるトラブルシュート
ローカル環境(kind)でingressを試す - 痒いところに手が届く
はじめに kind (kubernetes in docker)でIngressを作成したい場合、ingress controllerを使う必要があります。 しかし、ドキュメント通りに実行してもM1 macなどのApple シリコンでは動きません。 理由は hashicorp/http-echo が arm64に対応していないからです。 $ docker container run --rm hashicorp/http-echo:latest -text 'aaa' WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested runtime: fa
痒いところに手が届く
はじめに kind (kubernetes in docker)でIngressを作成したい場合、ingress controllerを使う必要があります。 しかし、ドキュメント通りに実行してもM1 macなどのApple シリコンでは動きません。 理由は hashicorp/http-echo が arm64に対応していないからです。 $ docker container run --rm hashicorp/http-echo:latest -text 'aaa' WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested runtime: fa
秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です
Kubernetes manifests を単一リポジトリで集中管理する運用設計 - LIVESENSE ENGINEER BLOG
Data Platform グループのリーダーの田中です。データ分析基盤 Livesense Analytics と機械学習基盤 Livesense Brain のプロジェクトマネジメント/アーキテクチャリングをしています。 今回は Livesense Brain における Kubernetes (k8s) manifest の管理方式と運用設計について紹介します。 2種類の管理方式: 個別管理と集中管理 k8sクラスタで複数のシステムを運用しmanifestをGit管理するとき、その管理方式は大きく次の2種類に分けられます。 個別管理: 各システムの実装を管理するGitリポジトリにmanifestを一緒に含める 集中管理: 各システムのリポジトリと別に、全manifestを管理する単一のリポジトリをおく 個別管理の場合、各システムのリポジトリで開発〜運用にかかわるすべてのコードを管理でき
KubernetesのモニタリングツールのKubesharkを触ってみた - 仮想化通信
Kubesharkとは 図は公式 より抜粋 KubesharkはKubernetesのための観測性・監視ツールで、マイクロサービスの動的解析、異常の検出などを実現するツールです。 Wireshark、BPF Compiler Collection（BCC）ツールなどを組み合わせた、Kubernetesを意識したものとお考えください...と説明されています。 Kubesharkは、クラスタ内の一部またはすべてのTCPトラフィックをスニッフィングし、PCAPファイルに記録し、HTTP1.0, HTTP1.1, HTTP2, AMQP, Apache Kafka, Redisなどのアプリケーション層プロトコルを分析できるとのことです。 今回はHTTPに絞って実際に環境を動かしてみて、トラフィックを覗いてみたいと思います。 Kuberentesクラスターの用意 まず、Kuberentesクラスター
Chaos meshでカオスエンジニアリング
導入 ローカル環境での導入 Run Your First Chaos Experiment in 10 Minutes ではkind or Minikubeが紹介されている． ~今回はMac上でkindを使う~ kindはarm未対応だった． Helmを使ってクラスタにインストール GKEにインストール % k get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME gke-chaos-mesh-default-pool-efa3374e-czdh Ready <none> 94m v1.21.5-gke.1802 10.128.0.9 34.71.110.66 Container-Optimized OS from Go
Chaos Mesh によるカオスエンジニアリング | sreake.com | 株式会社スリーシェイク
今回は Chaos Mesh を紹介します。 Chaos Mesh は Kubernetes 環境向けの Chaos Engineering ツールです。 Chaos Mesh によるカオスエンジニアリング Sreake の寺岡です。今回は Chaos Mesh を紹介します。 Chaos Mesh は Kubernetes 環境向けの Chaos Engineering ツールです。 カオスエンジニアリングの原則 カオスエンジニアリングと言えば本番環境で発生しうる Node 障害を日常のものにするということが元々の目的だったのではないかと思いますが、今日では意図的に障害を発生させること全般が対象となっているように感じます。まれに発生するトラブルを開発環境で意図的に発生させてコードの品質を上げるということが含まれてきているようです。 ここで紹介する Chaos Mesh も、開発元である
Chaos Meshによるラックのカオスエンジニアリング、あえて障害を起こす最新手法を検証 | LAC WATCH
システムを使う上で、障害を完全になくすことはできません。そして、いざ障害が発生し、システムが正常に動作しない状況に陥ると、多大な損害が発生することもあります。そのため、システム構築では障害に備えて冗長性を確保し、事前に障害検証を行い、障害が起きてもシステムが正常に動作することを確認します。 しかし、現在の主流である「分散システム」は、多数のサービスを組み合わせることで1つのシステムを実現させるため、規模が大きくなるにつれてシステムが複雑化していきます。それに伴い、障害検証の負荷も増えています。さらに、昨今コンテナを利用した「マイクロサービス化」によって、ますますサービスの数が増えて、システムの複雑化が一段と進んでいる状況です。既に人力だけでは障害検証を行っていくことが難しくなってきました。 そんな中、登場してきたのが今回お話する「カオスエンジニアリング」です。 Chaos Meshとは カ
Argo CD Resource Hookを活用したKubernetes環境での負荷試験自動化の取り組み - ZOZO TECH BLOG
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの渡辺です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。 先日私達のチームでは、リリースフローにステージング環境での負荷試験を自動化する取り組みを行いました。今回説明する「負荷試験の自動化」が何を表すのかを定義すると、ここではステージング環境のアプリケーションバージョンを変更した際に、人の手を介さずに負荷試験が行われることを指します。 Kubernetes環境における負荷試験の自動化を検討している方は是非参考にしてください。 目次 はじめに 目次 負荷試験を自動化する前の課題 負荷試験のシナリオ設計 目的設定 現状調査 目標値設定 シナリオ設計 負荷試験を自動化する取り組み 構成 処理の流れ シナリオに沿ったリクエストを送る 実行結果をS3に保存してSlackに通知する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
