おはこんばんちは、人事労務フリーのエンジニアを担当している橋本です。この記事は、freee Developers Advent Calendar 2019の6日目となります。 adventar.org 以前はSREに所属しており、この記事ではそのときの知見をご紹介いたします。 アプリケーションからのメール配送 早速ですが、表題のとおりアプリケーションにおけるメール配送を考えていきます。 freeeではお客様へのメール配送にSendGridを利用していますが、アプリケーションからSendGridに送信するまでの方法はいくつか考えられます。freeeでは以下の方法を検討しました。 SendGrid APIを用いてアプリケーションから直接SendGridへ送信する アプリケーションからPostfixに送信させ、SendGridにリレーする 最終的に後者の方法を採用することにしました。メリットとし

Kubernetesの主要なリソースの一つにServiceリソースがあります。ServiceリソースとはKubernetes上のPodへクラスタの外からアクセスするために使うもの、という理解をしている人が多いかもしれません。確かにそのような役割を担っているのですが、実際にはクラスタ内部に閉じた通信にも利用されていますし、実はもっといろいろな機能を持っています。 端的に説明すれば、Serviceとは「ロードバランサとDNSサーバを設定するためのリソース」です。意外に聞こえますか？ もし意外に思えたなら、ぜひこのまま読み進めてみてください。 インターナルなロードバランサを制御する Kubernetesにはクラスタ内部に閉じた通信を制御するロードバランサが内蔵されています。Kubernetesを利用するということは、ほぼ例外なくこのロードバランサを利用しているのですが、あまり意識せずに利用されて

社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 Kubernetesは現在は4ヶ月に一回マイナーアップグレードリリースが実施されています。そして、基本的には最新の3つのマイナーリリースについてサポートが行われるポリシーとなっています（深刻なセキュリティフィックスは例外）。 https://kubernetes.io/ja/docs/setup/release/version-skew-policy/ ところが、DataDogのレポートによると古いバージョンのKubernetesを使い続けている組織が多いのだそうです。Kubernetesは後方互換性が高いレベルで保た

はじめに CNCFのIncubating ProjectsであるコンテナリポジトリHarborを検証します。Harborは、Cloud Native Registryということで、Kubernetes上で運用することができるコンテナリポジトリです。プライベートクラウドなどで独自にコンテナリポジトリが欲しい方の選択肢の一つになるかと思います。機能としては、Multi-tenant、Image replication, コンテナイメージの脆弱性チェックなどの特徴を持っています。 今回の検証では、HarborをKubernetes上に構築、コンテナイメージをHarborへ格納、Kubernetesで格納したコンテナイメージをデプロイを行います。 環境 検証に使う環境として以下の環境を使います。 Kubernetes v1.13.2 (kubeadmで構築, Master x 1, Worker

どうやって決める？kubernetesでのシークレット管理方法 （Cloud Native Days 2020 発表資料） 2020年9月8日 株式会社NTTデータ デジタル技術部 里木、山田Read less

MS Ignite 2019というMicrosoft社のイベントで Mohammad Nofalさんにより話されていた、 AKSのクラスタ管理と高可用性に関するベストプラクティス (原題: Applying best practices to Azure Kubernetes Service (AKS)) について内容を紹介します。 前編では高可用性設計について説明します。 大まかにはMohammad Nofalさんの説明に沿ってますが、 自分が説明するとしたらこんな感じかな…という風に作成したので Nofalさんのセッションもご参照いただけると幸いです。 参考資料映像https://myignite.techcommunity.microsoft.com/sessions/81598?source=SessionDeck ソースコード等(スライドもあります)

こんにちは、もーすけです。 本日はKubernetesのノード障害が起きたときのPodの挙動について確認します。 いままで、ノード障害が起きたときのPodの挙動、スケジューリングについて誤った認識をしていました。 お恥ずかしい限りなのですが、同じような誤った認識をしているかたに向けて確認したことを解説します。 概要 まずはじめに、状況を説明します。Workerノード3台があって、アプリケーションが動作しているとします。 Worker#1がシャットダウンした、kubeletが停止した、ネットワーク的に疎通ができなくなったなどが起きたときに、その上で動いていてPodはどうなるの？という話です。 感覚的にいうと、レプリカ数を維持するために他のノードに移って起動するんでしょ！、と思いたいところなのですが、実際はそれほど単純でもありません。 どのような動きをしていくのか、Deploymentを使った

k8sクラスタのノードの一つが、ハードウェア障害などでダウンした場合の振る舞いについて検証した記録です。 検証システムの構成 Kubenetes v1.10 クラスタをVagrantで構築したメモのVagrantで構築したk8sクラスタを利用して、障害時の振る舞いについて、調べてみました。 マスターノードであるk8s1にもNodePortが動作していますから、このk8s1をロードバランサーに見立て、HTTPクライアントからk8s1のTCP31514をアクセスして、k8s2とk8s3のNginxのウェブサーバーをアクセスします。 そして、 k8s2 仮想サーバーの模擬障害としてシャットダウンした場合のクライアント視点での動作、ポッドのマイグレーションについて検証します。 正常稼働の状態 初期状態として、すべてが正常に稼働している状態の動作を確認しておきます。 この画面の表示は、上から順に、以

概要 自前の認証機能を持っていない、既存のウェブサイトや独自アプリがある Basic認証などで都度ID/パスワード設定するのは古臭いし管理たいへんなので止めたい シングルサインオンできる 自前の認証機能 を使いたい はじめに この記事は以下の続編です。 OAuth2 Proxyで外部認証(1) GitHub編 Keycloakによる認証基盤の立ち上げ(1) Wildfly版 OAuth2で「外部の」認証基盤を利用する仕組みは出来た。 Keycloakで「自前の」認証基盤立ち上げは出来た。 なので、（満を持して）自前の認証基盤でSSOできる仕組みへ移行。 設定の流れ OAuth2 Proxyのドキュメント確認 ドキュメントの Keycloak OIDC Auth Provider の項を見ておく。 この項と別に Keycloak Auth Provider という項もあるが、冒頭のnoteに

技術部プラットフォームグループ SRE の akichan です。 私が所属する技術部プラットフォームグループは SUZURI や minne といったサービスごとにある事業部に所属しないサービス横断のSREの集団です。運用の効率化、サービスレベル目標を達成できるようにするための支援を行っています。 今回はペパボのSREが普段利用している便利なツールの紹介を通し、具体的な業務の内容について知っていただこうと思います。 Kubernetes関連 SRE は各サービス事業部のKubernetesクラスタの管理者でもあります。 日常的なクラスタの維持管理や、トラブルシュートに対応します。 stern sternは複数のPodのログをまとめて見ることができるツールです。 kubectl logsを使ってPodのログをみる場合、Podの正確な名前を指定する必要があり手間です。 sternはPod名の

インフラ初心者がいきなり実務でKubernetesを使うことになったので、その学習記録✎ 流れとしては、 概念的なところを抑える 実際に手元で動かしてみる です！ また、すでにKubernetesについて書かれたわかりやすい記事がたくさんあるので、本記事はそれらをもとに自分の理解をまとめたものになります。 概念的なこと まずはこれで概要把握 まずは👇を読もう。（ありがたやありがたや...） 僕らは何故Kubernetesを使うのか Kubernetesというものが出てきた背景を、オンプレの時代からどういうふうに変わっていったかわかる KUbernetesの概要がわかる メリデメがわかる Argo CDの例などを用いてどういうふうに使われているのかイメージが付く Kubernetesとは ざっくりいうと、 サービスをコンテナ上で動かすようになったことで起こった、 複数のサーバ上で複数のコン

Istioのインストール、サイドカープロキシ（Envoy）の挿入、マイクロサービスの可視化：Cloud Nativeチートシート（10） Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Istioの環境構築と実践ポイントを説明します。

先日のContainer Runtime Meetup #3で「Podmanでkind動かせるよ」という話になり、どういうわけか「Podmanではkindは(まだ)動かせない」と思い込んでいたため、実際に試してみました。 ドキュメントは多分ないですが、 sudo KIND_EXPERIMENTAL_PROVIDER=podm…

※岡本、正野、宇都宮はNTTデータ所属 Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回から複数回に分けて「Observability（オブザーバビリティ）」「可観測性」にフォーカスして解説しています。 Kubernetesを使っていてトラブルが発生したけど、原因究明をどう進めればいいか分からない……ということはありませんか？ コンテナを利用したシステムでは、マイクロサービス化が容易なので、コンポーネントやサービスの数が従来のシステムに比べて非常に多くなります。そのため、障害が発生した場合の原因の究明も大変になります。 そこで今回は、「Observabilityでいろいろとデータが取れるのは分かったけど、何からどう見ていけばいいのか分からない」という方向けに、Kubernetesで実

はじめに CloudNative Days Tokyo 2021（CNDT2021）の配信プラットフォームにGrafana Helm Chartを導入したときにハマったことを紹介します。 以下のふりかえりポエムで予告していたものです。 Grafanaダッシュボードを作るうえでハマったことなど技術的な話は後日Zennに投稿予定です。Observability Conferenceまで引っ張るネタでもないので。 ハマりどころ Deploymentのローリングアップデートが進まない Grafana Helm Chartをpersistence.enabled = trueとしてインストールするとgrafanaはDeploymentとして作成され、そのDeployment StrategyはRollingUpdateです。 grafanaをローリングアップデートしようとすると、現PodがVolum

When setting up a Kubernetes Cluster in Azure you have the option to deploy using two different network plugins. Either using Kubernetes Kubenet or Azure CNI. So, what are the main differences between these two? to be honest there is also a lot of other considerations as well. Since Kubernetes networking can be complex. Before I go into the details, we need to just cover some basic Kubernetes Netw

前回は、Kubernetesの概要と背景にある考え方について、説明しました。 今回では、実際に簡単なWebアプリケーションをKubernetes上に構築するサンプルをご紹介します。 このサンプルアプリケーションは、SpringBootを使用したWebアプリケーションで、Kubernetesの構成を学ぶ上で、極力シンプルにしたものです。 アプリケーションの構成 前回の最後にアプリケーションの構成パターンとして、以下の３つを挙げましたが、いずれの場合も設定をどのように行うかは悩みどころです。 ミドルウエア（＋設定）のみ ミドルウエア（＋設定）+データのみ ミドルウエア＋アプリケーション＋設定 基本的に、アプリケーションの設定の大部分はdockerイメージにまとめられています。しかし、すべての環境設定がDockerイメージに含まれている場合、特にテスト、ステージング、実稼働環境、または特定の目的