(Kubernetesのチュートリアルが完全に終わってない...)
ちょっと前に参加した「GCPUGさん主催のGKEのお勉強会にいってきました」の件をようやく書き終えたのでどどーんと投下。
今回は女子会でした。GCPUG女子会。
女子〜な集まりは大抵ニガテなんですが、エンジニア女子の集まりは、なんかとっても ゆるふわなところが多くて、行きやすいと感じる今日この頃。
この日は
Cloud AceのGCP認定トレーナーさんが講師でした。(あとサポートにGoogleのエンジニアさんとかいた)
配布資料がなかったので、メモだけ。ググったメモも追加してます。
GKEとKubernetes
Kubernetes自体は、GCPだろうとAWSだろうと同じ〜
Kubernetesの世界をイメージする
- マトリョーシカのイメージ
- どんどん潜っってくイメージ
用語解説
クラスター
- いちばん外側のハコ
NodePool
- コンテナを起動するためのもの
- ひとつのクラスタ内で全てが同じように構成されたノードインスタンスのサブセット
- 特定のノードプール内のノードはすべて同一になる
- default node poolってなんだっけ?
- さまざまなマシンタイプを使用して、クラスタにノードプールを作成することができる
NodePoolはスペックによって分ける
- Webサーバーのスペックは軽めでいい
- DBのワークロードをのせるには、メモリがたくさんいる(リッチマシンタイプが必要)
という要件によって、NodePoolを選択する。
たとえば、ローカル SSD、最小 CPU プラットフォーム、プリエンプティブ VM、特定のノードイメージ、より大きなインスタンス サイズ、またはさまざまなマシンタイプを使用して、クラスタにノードプールを作成することができます。カスタム ノードプールは、他より多くのリソース(メモリやローカル ディスク容量など)を必要とするポッドをスケジュールする必要がある場合に便利です。
Google Cloudより
Node
- VMインスタンスのこと
- NodeはVMインスタンスで起動している
- NodePoolにあるNode(GCE VM)は複数のゾーンにまたがって配置することができる
その他メモ
- 本番で運用するの、けっこう大変です
ここからクーバの話
って言ってた。
KubernetesチュートリアルにNodeの話は出てきたけど、NodePoolは出てこなかった。。GKEの機能なのかな。
Pod
- Nodeの中にPodがある
- ひとつのPodが複数のコンテナを起動できる
- KubernetesのスケールはPod単位でおこなわれる
- Podの設計はymlファイルに記載する
- 設計図にはいくつか種類がある
- Podを作るのがKuberの仕事
Service
- Podにトラフィックを流す
- ユーザーがアクセスしてきたら、Podにつなぐ
どうやってサービスを受け付け、Podとサービスを紐づけるか
- Ingress -> Service → Pod
hoge.com/a
↓ ロードバランサーの外部IPに対してアクセス
Ingress(= GCPのHTTPLBが起動している)
↓
ServiceA / ServiceB (NodePort, LB)
ServiceA
↓
PodA / PodA
ServiceB
↓
PodB / PodB / PodB
Podを作るのに必要なもの
ReplicaSet
- 同じ定義の複数のPodを作成し分散に備える
Deployment
- ReplicaSetにバージョン管理がついたもの
- RollingUpdateした後に元のバージョンに戻すことができる
StatefulSet
- 分散データベースなどのステートフルなコンテナに使用する
- Podに対して永続ディスクが割り当てられる(モンゴちゃんとか、カサンドラちゃん とか)
NodePortをメインにお勉強する
ハンズオン中なぅ
メモ
- 1つのゾーンにつき何個のノードを起動するかオプション
- NUM_NODES
preemptible(プリエンプティブ)オプション
- 開発するときにに安くGCPが利用できる
- 24時間以内にストップするGCPのオプション
- 東京7割引の値段で使えるインスタンス?
- GKEでpreemptibleしても消えない(本番では使わないこと)
yamlファイルを確認しながら、流れをチェック(ここから、他人が読んでもわからんかも・・自分メモ)
- kubectl apply -f nginx.yaml
Podを作る設定図
deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3 ←重要(レプリカ数)
selector:
matchLabels:
app: nginx ←★一致させる
template:
metadata:
labels:
app: nginx ←★一致させる
spec:
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
readinessProbe:
initialDelaySeconds: 30
httpGet:
path: /
port: 80
livenessProbe:
periodSeconds: 60
httpGet:
path: /
port: 80
resources:
requests:
cpu: 200m
memory: 100Mi
limits:
cpu: 200m
memory: 100Mi
★ほしの部分、どのラベルを持ったPodを自分のレプリカとしてもつのか
- どのコンテナを使うかを containers: のところにかく
- Yamlのハイフンは配列を表してる!!(知らんかった!)
- name: nginx 名前はなんでもいい
Image: nginx:stable-alpine ←タグ DockerHubにあるnginxの種類 alpineっていう(アルパイン)単語(タグ)を覚えておくといい
- Image コンテナイメージ
アルパイン
- 軽量なOSのイメージ
- とっても軽くてスケールしやすい
- コンテナは軽さが正義
- アルパインをイメージしてwebサーバーを作ればいい
- アルパインはコンテナ会の常識らしい
readinessProbe
readinessProbe:30 ←30秒
- レディネスプローブ
- ヘルスチェック
- 準備状態を保証
- そのコンテナに、トラフィックを流しても大丈夫ですか?とかしてくれる
- 最初に30秒待った後に、Getリクエストをルートパスの80番に流す(yamlファイルに80番が指定されていたら)
- 正常に帰ってこなかったら、リクエストを流さないでくれる
livenessProbe
livenessProbe:
- 生きてますか?
- コンテナがお亡くなりなったらコンテナを再起動してくれる
- ワークロードの問題があってもコンテナを自動起動してくれる
Resource
- コンテナがどこまでリソースが必要で、どこまで使っていいかをしていいか指定する
そのほか
Requestsとlimitsを使って、リソースを確保する、ノードプールのスペックを決める、ノード数を決める?
ここまでがデプロイメントのお話
service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: NodePort ←このPodを担当したい??
selector:
app: nginx
ports:
- port: 80
targetPort: 80
ingress.yml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-ingress
spec:
rules:
- http:
paths:
- backend:
serviceName: nginx-svc ←ココ★
servicePort: 80
- このイングレスに到達するすべてのトラフィックはinginx-svc★の80番に流す
- Podの80番に流す(container port80へ流す)
- イングレスはIPアドレスをもっている
メモ
- Kubectl(キューブコントロール)
- 自動スケール
- 水平Podスケール
- Horizontal pod autoscaler(ユーザからのリクエスト数に応じてオートスケールができる)
最初の勉強は難しい本を読むより、Nodeport、Ingres、どうゆうyamlを書いたら動く?って書いてやったほうが良い。概念はあとにして、作りたいものを、まずyamlファイル書いて動かすべし。
Goで書いたAPIサーバーをクーバでどう動かしたらいいんだろう?って考えてみるとか
- ワークロードは、Podが最小単位
- 例えば、DBとその状態を監視するコンテナや、APサーバと、HTTPSの末端となるNGINXなど
- Pod内にはPrivateな仮想IPが振られており、Pod内のコンテナは、localhostで通信する
--
Podの作成の仕方には二種類あり、AP系(基本系)と、DB系がある
AP系は
- Deployment→Replicaset→Pod
という順で定義。Replicasetは同一のPodをn個作成する為のもので、DeploymentはReplicasetとほぼ同様だけど、敢えてDeploymentにする事で、ローリングアップデートが可能になる。
直接Podを作成するのではなく、Deploymetとして定義することによって、オートスケーリングやローリングアップデート、設定によってはオートスケーリングも可能になる。
あと、自分が所属しているTech系NPOのメンバーで、スタートアップ起業なぅなKubernetes猛勉中の若者に色々教えてもらった。。
どんどん触っていかないとわからんなぁ〜。