(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猛勉中の若者に色々教えてもらった。。
どんどん触っていかないとわからんなぁ〜。