Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • Kubernetes とは?
  • Object とは
  • よく聞く主な Object の役割(機能)
  • Object の階層構造
  • Wantedly での Kunbernetes 構成
  • デプロイについて
  • 環境変数・dotenv について
  • kube コマンド

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. Infrastructure

プロダクト開発のための Kubernetes 入門

前へInfrastructure Squad次へインフラ構成概要

最終更新 3 年前

役に立ちましたか?

Wantedly のバックエンドシステムは全て AWS 上に構築された クラスタの上で動いています。 新しいコードをデプロイしたり、開発用クラスタで rails c を実行したりなど日常の業務はインフラチームの助けを借りずにできるようになっています。   この章では、プロダクト開発に必要となる知識の説明をします。Kubernetes の基本的な概念、Wantedly における Kubernetes の構成、そしてその内製CLIである kube コマンドの概要を説明します。

Kubernetes とは?

Kubernetes における代表的な Object の階層構造と役割(機能) を知ることが重要です。より詳しくは公式ドキュメントのを参照してください。

Object とは

Kubernetes の管理下にあるレイヤのリソース(Container, Network, Storage, etc…)を抽象化したものを指します。詳細は公式ドキュメントのを参照してください。また、少し古いですがの記事群も図解が多めでわかりやすいです。

Object には spec(仕様)と state(状態)が存在しています。Kubernetes の根本的なコンセプトとして Reconciliation Loop によって Object で宣言された spec(desired state) に操作対象リソースの state を近づけるというものがあります。例えば Pod を 2 つ立てておいてくださいと spec に書いている状態で Pod が 1 つになってしまった(state)ら自動的にもう一台 Pod を立てるということを勝手にやってくれます。詳細はを参照してください。

よく聞く主な Object の役割(機能)

  • Namespace

    • Kubernetes 上のリソースを分類するための名前空間

    • 操作権限の境界

    • Object のグルーピング

    • ClusterRole(Binding) とか一部の Object 以外は必ずどこかの Namespace に所属している

      • Object の作成時に Namespace を指定しなかった場合は default Namespace が指定される

    • Wantedly においてはマイクロサービスごとに Namespace を作っている

      • e.g. wantedly/yashima-rails リポジトリ - yashima-rails namespace

  • Pod

    • Kubernetes におけるアプリケーションの最小構成単位

    • コンテナの集まり

      • 1 つの Pod に N 個の Container が含まれる

      • e.g. rails server などアプリケーションサーバ, nginx や envoy などの reverse proxy をひとまとめに扱う

  • Node

    • VM もしくは物理マシンに対応

      • Wantedly においては AWS 上の EC2 インスタンス

    • Node 上には複数の Pod がデプロイされる

  • ReplicaSet

    • Pod の管理

    • 指定した数の Pod の複製・維持

      • 例えば Pod を 2 台起動して欲しいと宣言しておくと、1 台 Pod が終了してもその直後に勝手に 1 台 Pod を起動して 2 台構成を維持してくれる

      • これを逆手にとって Pod を強制的に再起動したいときは Pod を delete することで消えた分の数の Pod が自動的に立ち上がる

        • ただこの場合 Pod の台数を維持できなくなる瞬間が存在する(Rolling Update ではないので 1 台構成とかだったらサービスダウンする)ので、複数台構成になっている前提

      • Deployment/ReplicaSet で管理された Pod を完全に削除したいという場合は Deployment/ReplicaSet を削除する

  • Deployment

    • ReplicaSet の世代管理

    • Pod の Rolling Update

    • 以前の ReplicaSet までの Rollback

  • CronJob

    • 指定した時刻に Job を起動する

  • Job

    • Pod を起動して指定された One Shot なコマンドを実行する

  • Service

    • Pod への通信を管理する

    • Pod に対する L4(TCP/IP) Load Balancer

    • Pod に対して通信しようと思ったら Service を追加しなければならない

  • Ingress

    • Pod(Service) への通信を管理する

    • Pod(Service) に対する L7(HTTP) Load Balancer

      • URL 上の Path でルーティングを切り替えるとかはこのレイヤでないと出来ない

    • この Object が実際に操作するのは Cloud Provider の Load Balancer が多い(Wantedly では ALB)

      • 他にも Kubernetes 内の Object も操作できる(e.g. nginx-ingress-controller とか)

Object の階層構造

Wantedly での Kunbernetes 構成

以下の3種類のクラスタが存在します。

  • Production

    • ユーザからのアクセスを受ける、いわゆる本番環境です。

  • QA

    • 本番デプロイ前の動作確認用クラスタです。

      • QAテスターチームが日常的に利用しています。社内のビジネスチームが動作確認のために利用することもあります。

    • 原則として、本番環境と同じバージョンのコードが動いている状態を保ちます。

    • モバイルアプリ・Web フロントエンドエンジニアは普段ローカルから QA につないで開発しています。

  • Sandbox

    • 開発用クラスタです。

    • バックエンドエンジニアが本番に近い環境でアプリケーションを動かしたいときに利用しています。

デプロイについて

より詳しくはリリース・デプロイ戦略の章を参照してください。

環境変数・dotenv について

kube コマンド

話を聞きに行きたい

もっと知りたい

Wantedly の Kubernetes クラスタ上で動いているアプリケーションは全て、 という Strategy でデプロイされます。これは動いているアプリケーション徐々に入れ替えていく方式で、古いアプリと新しいアプリが同時に動作する時間が存在することになります。 なので、Pull request を作るときには「バックエンドとフロントエンドの変更を分ける」「DB スキーマ変更とアプリケーション変更は分ける」などを意識することが重要になります。

の で、アプリケーションの設定値はコード上に記述せず環境変数にセットすることが推奨されています。 Wantedly の Kubernetes クラスタでは を利用し環境変数を管理しています。 各 Namespace に dotenv という Secret を作成し、そこに設定値を格納して環境変数に展開しています。 dotenv への環境変数の設定などは、後述する kube コマンドを介して行われます。

kube は Wantedly の Kubernetes クラスタのリソースを操作するためのユーティリティです。 詳しくは を参照してください。

Slack: ,

Kubernetes
Kubernetesとは何か?
Kubernetesオブジェクトを理解する
Kubernetes道場 Advent Calendar 2018 - Qiita
Kubernetes のしくみ やさしく学ぶ 内部構造とアーキテクチャー
Rolling update
The Twelve-Factor App
III. Config
Secret
kube - Wantedly Engineering Handbook
#infra
#dx
強いインフラが組織を創る / #jtf2018 - Speaker Deck
Kube - The core tool at Wantedly - Speaker Deck