Upload
ryosuke-suto
View
5.645
Download
4
Embed Size (px)
Citation preview
Google Container Engine と Kubernetes で 無理をしないコンテナ管理
株式会社サイバーエージェント 技術本部
サービスリライアビリティグループエンジニア兼マネージャー
須藤 涼介
2
自己紹介
● 須藤涼介(Suto Ryosuke)● 株式会社サイバーエージェント
● 技術本部サービスリライアビリティグループ(SRG)
● カスタマーサポート→アメーバピグ→ネットワーク→コミュニ
ティ系サービス→ソーシャルゲーム→AbemaTV
5
インターネットテレビ局「AbemaTV」
株式会社AbemaTV: 株式会社サイバーエージェントと株式会社テレビ朝日の共同出資により 2015年4月設立
会員登録不要 無料で利用可能 コメントや動画の投稿などの SNS連携機能
スマートデバイスに合わせた UI/UX 見逃し配信 オンデマンド機能(月額 960円)
テレビのような受け身視聴 24時間365日配信
8
● Master:クラスタを管理
○ GKEでは表示されない
● Minion:Dockerが起動するノード
● Pod:コンテナのグループ
● Replication Controller:起動するPod数や環境変数を管理(Replica Sets)
● Service:Pod郡のエンドポイント
Node1Minion1
RC1 Pod1-1
Pod1-2
Pod2-1
Pod2-2
Service1 Service2
Kubernetesの構成
9
apiVersion: v1kind: ReplicationControllermetadata: name: abema-xxxspec: replicas: 4 ←起動するPodの数 selector: name: abema-xxx template: metadata: labels: name: abema-xxx environment: dev spec: containers: - name: abema-xxx ↓環境変数 env: - name: ENV value: development - name: REDIS_ADDR value: redis-a:6379,redis-b:6379,redis-c:6379 image: asia.gcr.io/[projectid]/abema-xxx:v1.1.0 ports: ↑起動するDockerイメージとタグ - containerPort: 30500 protocol: TCP initialDelaySeconds: 15 timeoutSeconds: 5
apiVersion: v1kind: Servicemetadata: name: abema-xxx labels: name: abema-xxxspec: selector: name: abema-xxx ports: - port: 8484 ↓Pod郡にアクセスするためのポート
nodePort: 30200 protocol: TCP name: http type: NodePort
ReplicationController.yaml Service.yaml
10
GKE at AbemaTV
● ホストOS : Debian GNU/Linux 7
● Kubernetes v1.2.0
● Docker 1.9.1
● ベースイメージ : Alpine Linux, Ubuntu
11
なぜDockerを選択したか?
● マイクロサービスアーキテクチャとの親和性
○ 各機能ごとに機能開発、リリース、スケール計画
○ 追加機能でインフラの準備が必要ない
○ カナリアリリース
● 迅速で容易なスケーラビリティ
12
なぜGKEを選択したか
● 2015年8月にGKEの正式版が公開(GA)
● マネージドサービスとして提供されている
○ MasterやDockerレジストリの管理が不要
● インスタンスグループによるクラスター管理
● OSSによる活発な開発、アップデート
13
利用するメリット
● 実行環境の差がなくなる
● クラスタのスケールが容易
● Stackdriver Loggingとの連携
○ 各コンテナの標準出力はStackdriver Loggingに
15
Podとクラスタのオートスケール設計
● Podのスケール設定はKubernetesのHPA(Horizontal Pod Autoscaling)
● クラスタのスケール設定はGCEのInstance Group
● 協調するバランスが難しい
→現状は手動でコントロールしている
16
負荷試験でQuota制限
● 負荷試験でPodのスクラップ&ビルド増加● Cloud Logging APIのQuota制限
○ 負荷を調査したいのにログが出ない● Cloud Monitoring APIのQuota制限
○ 負荷を調査したいのにリソースが(以下略
17
運用してみての感想
● プロビジョニングツールがいらない
● DevとOpsの距離が近づく
○ アプリケーションエンジニアとインフラエンジニアが同じリ
リースフロー、開発サイクルで作業できる
■ Dockerイメージ作成
■ Replication Controller(Deployment)の更新