GCP GKE Kubernetes メモ

GCP

Kubernetesの構成概要

項目内容
kube-APIserverkubectlコマンドを受け付けるサーバ。
etcdkubernetes用データベースサーバ。
クラスタの構成データを格納するDB
kube-schedulerポッドをノードにスケジュールする。
kube-cloud-managerクラスタの状態をモニタリングし、宣言と一致するように構成を変更する。
kube-controller-managerクラウドプロバイダーとのやりとりを管理する。
kubeletノードごとのKubernetesエンジンのようなもの

Kubernetesのresource概要

Kubernetesのresourceとしては、大体こんな感じ。

DamonSetというresourceもあったりする。
各ノードに必ずあるポッドAを配置したい場合等の要件の時に使える。

コンテナイメージの保存

コンテナは以下のリポジトリサービスに登録しておく必要がある。

項目内容
Container RegistryDocker コンテナイメージを保存、管理、保護する。
Artifact Registry次世代のContainer Registry。
ビルドアーティファクトクトを保存、管理、保護する。
言語パッケージの管理や、Googleクラウドのツールとの連携が強化。

コンテナはURL(ホスト名)でイメージ保管先の地域を指定することができる。

ホスト名(URL)内容
gcr.io米国内のデータセンター
us.gcr.io米国内のデータセンター。gcr.ioからは独立
eu.gcr.io欧州連合のデータセンター
asia.gcr.ioアジアのデータセンター

レジストリの利用方法は以下。

### ソースとなるイメージをpull
$ docker pull centos:centos7
$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
centos       centos7   8652b9f0cb4c   3 months ago   204MB

### イメージを指定し、コンテナを作成、起動
$ docker run -it -d --name centos7cus centos:centos7

### 起動確認
$ docker ps
CONTAINER ID   IMAGE            COMMAND       CREATED         STATUS         PORTS     NAMES
c6547e3af302   centos:centos7   "/bin/bash"   6 seconds ago   Up 5 seconds             centos7cus

### 追加で/bin/bashを起動し、コンテナにアタッチ
$ docker exec -it centos7cus /bin/bash
(コンテナ)# ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 00:20 pts/0    00:00:00 /bin/bash #親プロセスとしての/bin/bash
root          16       0  1 00:24 pts/1    00:00:00 /bin/bash #追加で起動した/bin/bash (exitしたらこっちが落ちる)
root          30      16  0 00:24 pts/1    00:00:00 ps -ef
(コンテナ)# exit

### イメージの作成
$ docker commit centos7cus centos7gcp
$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
centos7gcp   latest    73649d11c901   42 seconds ago   204MB #新規に作成したイメージ
centos       centos7   8652b9f0cb4c   3 months ago     204MB

### Cloud Registryへの登録前準備(タグ付け)
### asiaのデータセンターにtest-project-11223のプロジェクトでイメージ名をcentos7gcp2でタグ付け
$ docker tag centos7gcp asia.gcr.io/test-project-11223/centos7gcp2
$ docker images
REPOSITORY                                   TAG       IMAGE ID       CREATED         SIZE
asia.gcr.io/test-project-11223/centos7gcp2   latest    73649d11c901   6 minutes ago   204MB
centos7gcp                                   latest    73649d11c901   6 minutes ago   204MB
centos                                       centos7   8652b9f0cb4c   3 months ago    204MB

### gclouddでのコンテナレジストリへの認証情報の設定
(Cloud Shellだと最初っから実施されてるので不要)
$ gcloud auth login
$ gcloud auth activate-service-account ACCOUNT --key-file=KEY-FILE
$ gcloud auth configure-docker
$ cat $HOME/.docker/config.json

### Cloud RegistryへPush
$ docker push asia.gcr.io/test-project-11223/centos7gcp2

コンテナのビルド

Dockerのイメージを作成する際には2つの方法がある。
docker commitだと、どういう構成なのかが宣言されていないので管理が煩雑になりがち?
Dockerfileを準備して、buildして、イメージの構成情報はDockerfileを管理する方式のが吉。

### Dockerfileからビルドする
$ docker build -t イメージ名 Dockerfileがあるディレクトリ
$ docker build -t testimage .

### 既存のコンテナをイメージ化
$ docker commit ソースコンテナ イメージ名

Cloud Buildを利用すると、Dockerfileを準備するだけでクラウド上でビルドが行える。

コンテナ イメージのビルド  |  Cloud Build のドキュメント  |  Google Cloud

Kubernetesの宣言方法

Kubernetesオブジェクトを理解する
このページでは、KubernetesオブジェクトがKubernetes APIでどのように表現されているか、またそれらを.yamlフォーマットでどのように表現するかを説明します。 Kubernetesオブジェクトを理解する Kubernetesオブジェクト は、Kubernetes上で永続的なエンティティです。Kube...

resourceの宣言はyaml

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
項目内容
apiVersionKubernetesAPIのバージョンを指定
kind作成するオブジェクトの種類
metadataオブジェクトを一意に特定するための情報
specオブジェクトの望ましい状態

クラスタの作成

クラスタの作成時には、クラスタをどういう構成で構築するかを設定できる。

ノードはOSイメージからCPUメモリディスクといったところまで設定が可能。

基本的な項目でいじるとしたらここまでかと思うので、他の細かな部分は割愛。
クラスタの作成が完了すると、VMインスタンスにGKE用のノードが作成されている。

作成されたノードはインスタンスグループで管理されている。

コンテナのデプロイ

コンテナのデプロイはワークロードから実施する。
コンテナイメージはあらかじめContainer RegistryかArtifact Registryに登録しておく必要がある。

現状ではイメージが準備できていないので、デフォルトで利用可能なnginxのイメージを使う。

次のステップの構成では、デプロイするコンテナのYAMLを確認したりできる。
同じイメージをデプロイしたければ、YAMLを保存しておくと良い。

---
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "nginx-1"
  namespace: "default"
  labels:
    app: "nginx-1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: "nginx-1"
  template:
    metadata:
      labels:
        app: "nginx-1"
    spec:
      containers:
      - name: "nginx-1"
        image: "nginx:latest"
---
apiVersion: "autoscaling/v2beta1"
kind: "HorizontalPodAutoscaler"
metadata:
  name: "nginx-1-hpa-d0dc"
  namespace: "default"
  labels:
    app: "nginx-1"
spec:
  scaleTargetRef:
    kind: "Deployment"
    name: "nginx-1"
    apiVersion: "apps/v1"
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: "Resource"
    resource:
      name: "cpu"
      targetAverageUtilization: 80

コンテナの構成要素
いったんここで、コンテナの構成要素の復習をする。
Kubernetesとしては、大体こんな感じ。

各種要素の情報を確認したい場合、ワークロードから確認する。
アクティブなリビジョンがReplicaSet、マネージドPodがPod。

デプロイしたnginxのYAML(Pod)
今回デプロイしたnginxは1Pod1コンテナのシンプルな構成。
重要そうな部分のみをピックアップ。

apiVersion: v1
kind: Pod # PodのYAMLであることを宣言
metadata:
(snip)
  name: nginx-1-9c9488bdb-pg6wx # Podの名前はnginx-1-9c9488bdb-pg6wx
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet # 上位にnginx-1-9c9488bdbのReplica Setがいる。
    name: nginx-1-9c9488bdb
    uid: a32a46e1-e339-4650-8843-6b1142eabb11
(snip)
spec:
  containers: # Podを構成するコンテナの宣言
  - image: nginx:latest
    imagePullPolicy: Always
    name: nginx-1 # nginx-1というコンテナが含まれている。
    resources:
      requests:
        cpu: 100m
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-kcldm
      readOnly: true
(snip)

これ以外にも、Deployment、ReplicaSetのページから各種要素のYAMLも確認ができる。

コンテナへのアタッチ

$ gcloud container clusters get-credentials cluster-1 --zone us-central1-c --project プロジェクト名
$ kubectl exec --stdin --tty nginx-1-9c9488bdb-pg6wx -- /bin/bash

参考URL

kubectl 用のクラスタ アクセスの構成  |  Kubernetes Engine ドキュメント  |  Google Cloud

サービスの公開

サービスを公開するとService、Ingress(ロードバランサ)が展開され、外部IPでアクセス可能になる。

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2021-01-21T01:55:43Z"
  finalizers:
  - service.kubernetes.io/load-balancer-cleanup
  labels:
    app: nginx-1
  name: nginx-1-service
  namespace: default
  resourceVersion: "25980"
  selfLink: /api/v1/namespaces/default/services/nginx-1-service
  uid: 76b8036a-176a-48de-aa24-03e7849ecf18
spec:
  clusterIP: 10.8.14.37
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30354
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-1
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 35.223.221.126

ゾーンクラスタ、リージョンクラスタ

単一ゾーンクラスタ

項目内容
コントロールプレーンus-central1-c
ノードus-central1-c

マルチゾーンクラスタ

コントロールプレーンが置いてあるゾーンがマスターゾーンとなる。
ノードは各ゾーンに分散するが、コントロールプレーンは単一ゾーンとなる。

項目内容
コントロールプレーンus-central1-c
ノードus-central1-a/b/c

リージョンクラスタ

リージョンクラスタの場合、デフォルトでノードはマルチゾーンで配置される。
コントロールプレーンも各ゾーンごとに設置が行われる。

項目内容
コントロールプレーンus-central1(a/b/c)
ノードus-central1(a/b/c)

コメント

タイトルとURLをコピーしました