最近良く聞く Kubernetes を体験してみたイントロ + 活用編

2019/2/22最近よく聞く Kubernetes を体験してみた 1/30
最近よく聞く Kubernetes を体験してみた
橋本修太武山文信
日本 openSUSE ユーザ会

本日の内容
●
少しだけ openSUSE の紹介
●
Kubernetes クラスタ構築してみた
●
Kubernetes で自作のアプリを動かしてみる

みなさん
って何かご存知ですか？

正しいのはどれ？
●
1. サーバールームでモフモフできるカメレオン型ガジェット
●
2. Ruby で簡単に Web アプリを作れるフレームワーク
●
3. 1996年にドイツで生まれた Linux ディストリビューション

正解: 3
●
3. 20年以上前にドイツで生まれた Linux ディストリビューション
– 1996 年: S.u.S.E Linux 4.2 リリース
●
これ以前は Slackware + 設定ツールでした
●
Q: RedHat 系ですか？ Debian 系ですか？
A: どちらでもありません！ Slackware系でもありません
●
Q: OpenSUSE ですか？openSUSE ですか？
A: o は小文字です。IPhone ではなく、iPhone なのと同じです

2つの openSUSE
Tumbleweed
常に最新安定
新しいカーネルやライブラリを使いたい人
アプリケーションのテスト環境
有償サポートが不要な人
普段遣いのデスクトップやサーバーに

openSUSE Leap 15.0 1/2
●
SUSE Linux Enterprise 15 ベースの安定志向
ディストリビューション
●
エンタープライズ版に openSUSE 独自のパッケージを追加
– CentOS + Fedora のような感じ
– デスクトップ環境:
Plasma 5.12, GNOME 3.26, XFCE 4.12, MATE, LXQt, etc.

openSUSE Leap 15.0 2/2
●
年に1回のマイナーアップデート（サービスパック）
– 15.1, 15.2, 15.3, …
– 15.1 は 2019年5月リリース予定
– 3年に1度程度のメジャーアップデート
●
1つ前のバージョンは 42.3 でした
– 15.0 のほうが新しいので注意！
– 42.3 は2019年6月末までサポート

スナップショット
新機能: トランザクショナルアップデート
●
Btrfs を活用した機能がいろいろ
●
トランザクショナルアップデート:
スナップショットを使って、複数のパッケージを同時にアップデート
– パッケージの不整合防止のダウンタイムを再起動の時間だけに
– 詳しくは OSC 2018 Tokyo/Fall のスライドで
ストレージ上の
データ
/ libB.so libC.so/usr/bin/A
実行中
/usr/bin/A libB.so libC.so
Updated Updated
古いファイル

同人誌も書いています
●
コミックマーケットC95で頒布
●
内容
– openSUSE で Google Drive を使う
– Kubic でお手軽 Kubernetes クラス
タ構築
– いまさらだけど… Let’s Encrypt で
HTTPS を使えるようにする
– openSUSE Leap 15.0 でハチプロ
を鳴らしてみよう
●
お買い求めはブースで！

前半 : 構築編

自作の Web アプリケーションを
Kubernetes クラスタにデプロイしてみた
武山文信
日本 openSUSE ユーザ会

よくあるイメージ
Kubernetes って大規模システムでしか
役に立たないのかな？
1 ノード構成でも使えるところがあるのでは？

docker-compose + 便利機能？
●
リモート端末から直接コンテナを管理できる
– クラスタ側に SSH ログインできるようにする必要なし
●
豊富な REST API を通したアプリ連携
– GitLab から CI で連携したり…
●
パフォーマンス、可用性…
Kubernetes クラスタ
今回は対象外です
コンテナコンテナ
コンテナ
コンテナ
$ kubectl

開発環境
●
openSUSE Kubic をノート PC の KVM 上にインストール
●
Master Node と Worker Node を1つにまとめる細工
– VM を何個も動かしたくない
– Master node への配置制限の解除
●
クラウドで提供されている K8s のほうが色々楽
– Google Cloud Platform、Azure、IBM Cloud、…
– オンプレでもクラウドでも使えるのが K8s 利点
$ kubectl taint nodes ノード名 node-role.kubernetes.io/master:NoSchedule-

題材: 自作 Web アプリ Radish
●
Ruby on Rails で実装した
Connpass っぽいイベント参加登録アプリ（作りかけ）
– 本当に作りかけなので
まだ使い物になりません
●
作業の流れ
1. アプリをコンテナ化する
2. K8s クラスタへのデプロイ
Dockerfile, イメージ、
ここで紹介する K8s の各種定義、ソースコード
https://gitlab.com/ftake/radish

1. アプリのコンテナ対応
●
コンテナを立ち上げたら、すぐ動くようにする
●
Stateless にする
– コンテナを作り直したときにデータが失われないよう、
データをアプリコンテナ外のデータベース（PostgreSQL）へ
●
データベースのデータは永続化するように設定（後述）
●
コンテナイメージをレジストリに配置する
– ローカルでビルドし、
K8s クラスタがアクセスできるレジストリに push が必要
– GitLab のレジストリを使用
●
別の方法: ローカルレジストリを作成する
https://blog.geeko.jp/ftake/1749
ローカルDockerとの違い
コンテナをいつでも
再生成できるように

2. K8s クラスタへのデプロイ
●
コンテナ（K8s 用語では Pod）の構成
– radish-server: Rails アプリのコンテナ
– postgresql: PostgreSQL のコンテナ
●
保存しておくべきデータはここに
radish-server
コンテナ (Pod)
Postgresql
コンテナ (Pod)
ブラウザ
直接は通信できない（後述）

まずは PostgreSQL を動かす
●
必要なものは主に3つ
– Service
クラスタ内から参照できる名前 + ポートで
コンテナがサービスを提供することを宣言する
●
tcp://postgresql:5432
– Deployment
どのようなコンテナ（Pod）を
何個立ち上げるか
●
postgresql:10 イメージのコンテナを 1個
– PersistentVolume（永続ボリューム）
データを永続的に保存しておく領域
postgres
Service
postgres
コンテナ (Pod)
postgres-pv
PersistentVolume
他の Pod

YAML ファイル
●
docker-compose のように
コンテナの定義を YAML で書く
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: radish
name: postgresql
spec:
<< …中略… >>
strategy:
type: Recreate
template:
metadata:
labels:
app: postgresql
spec:
containers:
- name: postgresql
image: postgres:10
env:
- <<…後述…>>
<< 続く >>
apiVersion: v1
kind: Service
metadata:
namespace: radish
name: postgresql
spec:
selector:
app: postgresql
type: ClusterIP
clusterIP: None
ports:
- port: 5432
Service
tcp://postgresql:5432
提供されるサービスがある
Deployment:
postgres:10 イメージ
でコンテナを1つ起動
app: postgresql を持つ
コンテナがサービスを提供

PostgreSQL の保存先を作る
apiVersion: v1
kind: PersistentVolume
metadata:
namespace: radish
name: radish-db-pv
labels:
type: local
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
storageClassName: standard
hostPath:
path: /var/lib/radish/db
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
namespace: radish
name: radish-db-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: standard
<<postgresqlのDeploymentの続き>>
containers:
- name: postgresql
image: postgres:10
Env: <<略>>
volumeMounts:
- name: data-dir
mountPath: /var/lib/postgresql/data
volumes:
- name: data-dir
persistentVolumeClaim:
claimName: radish-db-pvc
DBのデータディレクトリを
永続ボリュームに
Claimを満たすVolumeを
k8sが割り当て
Nodeの/var/lib/radish/db
に領域を確保

Apply でリソースを作成
●
定義ファイルを書いたら kubectl apply でリソースを作成する
– 修正したら再度 kubectl apply して OK
●
何個もリソースが作り直されることはない（一種のべき等性）
$ kubectl apply -f kube/postgresql.yml
$ kubectl apply -f kube/radish-db.yml
$ kubectl apply -f kube
$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
postgresql-7dd686946c-jdw8m   1/1       Running   1          12s
$ kubectl get service
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
postgresql   ClusterIP   None             <none>        5432/TCP         12s
ディレクトリ指定も可
コンテナとサービス状態取得

便利機能1: Name space
●
Radishで使用する k8s のリソース（Pod, Service）をまとめる
– アクセス制御にも使えるが…今回はスキップ
$ docker ps
CONTAINER ID IMAGE ...
852e3e9d0756 radish:master ...
e03bc13bf859 postgres:10
92ad9078be0e busybox
1215054fd637 registry
ac74b987a567 portus
3ef7fb2aa6ce jenkins
13f540dad13f redmine
$ kubectl -n radish get pods
NAME READY ...
postgresql-c9cc48968-k8wfn 1/1 ...
radish-d7554c44b-lb9rr 1/1
色々なコンテナが
たくさん出てくる
radish 関連のコンテナのみ

便利機能2: ConfigMap と Secret
●
設定っぽいものをまとめておける
– ConfigMap: 一般用
– Secret: API キーとか
●
Deployment で環境変数値を
設定するときに参照できる
kind: ConfigMap
metadata:
name: radish-config
namespace: radish
data:
db.user: postgres
db.name: radish
kind: Secret
metadata:
name: radish-secret
namespace: radish
data: {}
stringData:
db.password: pAS$w0rd
rails.secret_key_base: 3447ef705b…
<< Deployment の一部 >>
env:
- name: RADISH_DB_USER
valueFrom:
configMapKeyRef:
name: radish-config
key: db.user
- name: RADISH_DB_PASSWORD
valueFrom:
secretKeyRef:
name: radish-secret
key: db.password

アプリを動かす
●
同じように
Deployment と
Service を書く
●
$ kubectl apply
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: radish
name: radish
spec:
selector:
matchLabels:
app: radish
template:
metadata:
labels:
app: radish
spec:
containers:
- name: radish-server
image: registry.gitlab.com/ftake/radish:master
imagePullPolicy: Always
command: ["bundle", "exec", "rails", "s"]
env:
<< 長いので省略 >>
ports:
- containerPort: 3000
apiVersion: v1
kind: Service
metadata:
namespace: radish
name: radish
spec:
selector:
app: radish
type: NodePort
ports:
- port: 3000
nodePort: 30080

データベースの初期化
●
コンテナ内のコマンドを実行したい
●
kubectl exec で実行できる
– 引数は Docker と同じ
– コンテナがどこのノードで動いているか気にしなくて良い！
●
●
●
Job という方法もあるらしい
# コンテナ（pod）の名前を調べる
$ kubectl get pods -n radish
NAME READY STATUS RESTARTS AGE
postgresql-7dd686946c-jdw8m 1/1 Running 0 2d
radish-d7554c44b-lb9rr 1/1 Running 0 3d
$ kubectl exec -ti radish-d7554c44b-lb9rr /bin/bash
# ここからはコンテナの中
$ DISABLE_DATABASE_ENVIRONMENT_CHECK=1 rails db:reset

外からアクセスする
●
サービスをクラスタの外に公開する
– 方法1: ポートフォワード
サービスを Node のポートにマッピング
– 方法2: Ingress Nginx Controller
URL のパターンで Service に転送
●
どの Worker Node に転送する？
– Load balancer を使う
●
MetalLB: K8s クラスタからルーターのルーティングをコントロール
●
IaaS であれば、提供されているものを使用
– 耐障害性を無視するなら（1ノードなら）決め打ち
http://ノード1のIPアドレス:30080/
●
Node まで届ければ kube-proxy が Service に応じてコンテナへ
apiVersion: v1
kind: Service
metadata:
namespace: radish
name: radish
spec:
selector:
app: radish
type: NodePort
ports:
- port: 3000
nodePort: 30080
ポートフォワード

感想
●
抽象化レイヤー（Service, PersistentVolumeClaim）で
実体の差し替えが容易であるが、記述が冗長
●
各リソースの設定ファイルは書いていればなんとなく分かってくる
– 最初は意味不明
●
外部からのアクセスをどうノードに振り分けるかは
色々考える必要があり大変

最近良く聞く Kubernetes を体験してみたイントロ + 活用編

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 最近良く聞く Kubernetes を体験してみたイントロ + 活用編

Ähnlich wie 最近良く聞く Kubernetes を体験してみたイントロ + 活用編 (20)

Mehr von Fuminobu Takeyama

Mehr von Fuminobu Takeyama (20)