Kubernetes完全ガイド 第二版 読書メモ
5章 WorkloadsAPIsカテゴリ
Pod
Workloadsリソースの最小単位
一つ以上のコンテナから構成
同じPodに含まれるコンテナ同士はネットワーク的に隔離されていない
IPアドレスを共有
Pod内のコンテナ同士はlocalhost宛で通信が可能
多くの場合は1Pod 1コンテナだが、メインのコンテナ以外に、補助のサブコンテナを持つことがある
サブコンテナとは例えば、プロキシの役割をするコンテナ、設定値の動的な書き換えを行うコンテナなど
Podのデザインパターン
サイドカーパターン
メインに加えて、補助的な機能を追加するコンテナを内包したパターン
Podはデータ領域を共有して持てるので、多くの場合はデータや設定にまつわるパターン
アンバサダーパターン
メインのコンテナが外部のシステムと接続する際に代理で中継を行うコンテナを内包したパターン
メインからは接続先にlocalhostを指定してアンバサダーコンテナにアクセス
例えば、開発環境は単一のデータベースを使うが、本番では分割されたデータベースの場合
アンバサダーを仲介することで、特定のDBと紐づくことを防げる
アダプタパターン
外部からのリクエストに対して差分を吸収するコンテナを内包したパターン
Prometheusなどの監視ソフトウェアに対して、要求を満たすようにメトリクスを整形する、と言った活用
コンテナへのログインとコマンドの実行
コンテナへのログインは、実際にSSHのようにコンテナにログインしているわけではない
疑似端末を生成(-t)して、標準入力をパススルー(-i)しながら/bin/bashを起動している
code:bash
$ kubectl exec -it samle-pod -- /bin/bash
root@sample-pod:/#
ENTRYPOINT命令/CMD命令と、command/args
Dockerとは少し異なり、ENTRYPOINTのことをcommand, CMDのことをargsと呼ぶ
コンテナ実行時にDockerイメージのENTRYPOINTとCMDを上書きするには、Pod定義に記述
code:sample-endpoint.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-endpoint
spec:
containers:
- name: nginx-container-112
image: nginx: 1.16
ホストのネットワーク構成を利用したPodの起動
k8sで起動するPodに割り当てられるIPアドレスはk8s NodeのホストのIPアドレスとレンジが異なる
外部からは疎通性がないIPアドレスが払い出される
ホストのネットワークを利用する設定spec.hostNetworkを有効化することで、ホスト上でただプロセスを起動するのと同等のネットワーク構成(IPアドレス、DNS設定、hosts設定など)でPodを起動できる
hostNetworkを利用したPodはk8s NodeのIPアドレスを利用する関係上、ポート番号を衝突させられない
基本的には利用しないで、NodePort Serviceで解決するのが良い
6章 ServiceAPIsカテゴリ
Service
L4ロードバランシング
7種類のService Type
Ingress
L7ロードバランシング
KubernetesクラスタのネットワークとService
おさらい
Podは複数のコンテナを内包できる
この場合、各コンテナのIPアドレスは同じ
localhostで通信できる
別のPodから通信を行う場合は、Pod IPを指定
k8sクラスタの内部ネットワーク
CNIによって少し異なる
基本的にはノードごとに異なるネットワークセグメントを構成
さらにノード間のトラフィックはVXLANやL2 Routingなどで転送して通信を実現する
Pod同士は最初からIPアドレスで通信できるけど、Serviceを使うともっと便利になる
Pod宛トラフィックのロードバランシング
サービスディスカバリーとクラスタ内DNS
Pod宛トラフィックのロードバランシング
Serviceは、受信したトラフィックを複数のPodにロードバランシングする機能を提供する
Podは起動ごとにIPが変わる
code:yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-deployment
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
containers:
- name: nginx-container
image: amsy810/echo-nginx:v2.0
このDeploymentに対応するServiceを作成
ClusterIPで作る
クラスタ内でのみ利用可能な仮想IPを持つエンドポイントを提供するロードバランサを構成する
code:yaml
apiVersion: v1
kind: Service
metadata:
name: sample-clusterip
spec:
type: ClusterIP
ports:
- name: "http-port"
protocol: "TCP"
port: 8080
targetPort: 80
selector:
app: sample0app
ClusterIPはあくまでクラスタ内からのみアクセスできる仮想IPアドレスが割り当てられるので、クラスタ内にPodを立ててアクセスできるか確認することができる
外からは不可能
Ingress
大きく分けて二種類ある
GKE Ingress
Nginx Ingress
クラスタ内にIngress用のPodをデプロイするIngress
Nginx Ingressのこと
L7ロードバランサとして、k8sクラスタ上にPodを立てる
このPodにはNginxを使う
ロードバランサがNginx Podまで転送し、その後NginxがL7相当の処理を行いPodに転送
Nginx Podから対象のPodまではNodePortを通らず、直接PodのIPアドレスに送られる
リクエストの経路
1. クライアント
2. L4 LoadBalancer(type: LoadBalancer)
3. Nginx Pod(Nginx Ingress Controller)
4. 転送先のPod
Ingress Controllerのデプロイ
GKE Ingress Controllerのデプロイ
GKEの場合、クラスタ作成時にHttpLoadBalancingアドオンを有効化することでデプロイされる
Nginx Ingress Controllerのデプロイ
自前で頑張る(それはそう)
ルートに一致しない場合のデフォルトの転送先Deploymentも必要
404.htmlを配信するだけのPodでOK
バックエンドのPodがオートスケールできるようになるためには、HPAも利用する
Ingress Controllerの一式をデプロイするためのマニフェストはGitHub上にあるので便利
Helmで設定をカスタムしてデプロイもできる
Ingressリソースを作成する前の事前準備
自己証明書の作り方
code:bash
# 自己署名証明書の作成
$ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
-keyout ~/tls.key -out ~/tls.crt -subj "/CN=sample.example.com"
Nginx Ingress用のIngressリソース作成
Nginx Ingressを利用する場合は、kubernetes.io/ingress.class: nginxアノテーションを付与する必要がある
これでIngressClassの指定ができるっぽいosamtimizer.icon
7章 Config & StorageAPIsカテゴリ
Secret
ConfigMap
PersistentVolumeClaim
configMap
設定情報などのKey-Valueで保持できるデータを保存しておくリソース
Podでの使い方は大きく分けて二通り
環境変数として渡す
Volumeとしてマウント
さらに、それぞれ
特定のKeyのみマウント
ConfigMap全体をマウント
ができる
特定のKeyのみ環境変数として渡す
code:yaml
containers:
- name: hoge-container
image: nginx
env:
- name: CONNECTION_MAX
value_from:
configMapKeyRef:
name: sample-configmap
key: connection.max
特定のキーをVolumeマウント
code:yaml
apiVersion: v1
kind: Pod
metadata:
name: sample-configmap-single-volume
spec:
containers:
- name: ocnfigmap-container
image: nginx
volumeMounts:
- name: config-volume
mounthPath: /config
volumes:
- name: config-volume
configMap:
name: sample-configmap
items:
- key: nginx.conf
path: nginx-sample.conf
Secret/ConfigMapのデータマウント時に、パーミッションを変更する
顧客の求めてたものじゃんosamtimizer.icon
ConfigMapやSecretをマウントしたファイルのパーミッションはデフォで644
code:Yaml
spec:
containers:
- name: configmap-container
image: nginx
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:
name: sample-configmap
items:
- key: test.sh
path: test.sh
mode: 493 # 0755(を10進数表記したもの)
table:permission
10進数 8進数 rwx
256 0400 r--------
384 0600 rw-------
420 0644 rw-r--r--
448 0700 rwx------
493 0755 rwxr-xr-x
511 0777 rwxrwxrwx