Kubernetesのyamlファイルに必須の項目について
Kubernetesの勉強をはじめると、設定が記載されたyamlファイルをよく見るようになります。
でもサンプルコードを見ると多くのフィールドがあり、何を見たらいいかわからなくなるという...。
ということで、まずは必須の4つのフィールドをまとめます。
- apiVersion
- kind
- metadata
- spec
サンプルコード
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80apiVersion
リソースのオブジェクトを作成時に利用するKubernetesAPIのバージョン
サンプルコードだと「apps/v1」バージョンを使うよ、と設定してます。
Kubernetesでは、マイナーバージョン毎に新機能の追加や、古い機能の非推奨化・廃止が実施されます。
Kubernetesのバージョンアップ時には、リソースのapiVersionの設定が非推奨となった場合、書き換える必要があります。
下記ドキュメントには、各オブジェクトのバージョンの状況や、非推奨APIからの移行方法が記載されてます。
kind
作成するリソースの種類
PodとかDeploymentとか、Kubernetesには色々な種類のリソースがありますが、
yamlファイルが何のリソースの設定かを記載します。
サンプルコードをみると、Deploymentの設定になっています。
metadata
オブジェクトを一意に特定するための情報。
nameとかUID、またnamespaceの情報が記載されます。
サンプルコードを見るとnginx-deploymentという名前のDeploymentになっています。
spec
オブジェクトの望ましい状態を表す設定（いっぱいいろいろ）
リソースの設定を見たければここ見てって感じでしょうか。
サンプルコードではselectorやreplicas、templateが設定されています。
specに記載できるフィールドは、各リソースそれぞれで設定されています。
どんなフィールドが設定できるかは、Kubernetes API リファレンスを見るといいらしいです。
Podに関するのはPodSpec v1 coreを、Deploymentに関するのはDeploymentSpec v1 appsを確認してねとのこと。
データベースのインデックス（索引）B-treeインデックス
フルスキャン
テーブルに格納されたデータを取り出す方法として、 フルスキャン
テーブルの全レコードから検索に一致する行をチェックする
全レコードを確認するため、検索にかかるコストは、レコード数に比例して増える
- データ追加の場合は、ファイルの末尾に1レコード分のデータが付け足される
全レコードをスキャンするので、レコード数の多いテーブルには向かない。
インデックススキャン
フルスキャンだと効率が悪いので、より速くデータにアクセスするためのアイデアとして、インデックスがある。
全レコード見なくてすむようにするためには？ 索引的なことができるように、メタデータをつくる。 ある検索条件にソート済みのメタデータを用意する。メタデータには実際に値があるデータに対するポインタが含まれている。
B-treeインデックス
インデックスの中にも様々な種類がある。その一つがB-treeインデックス - アイデア：ソート済みのデータをいくつかのレンジに分割して、検索範囲を削減する
まず対象がどのレンジに含まれるかを検索、その後レンジに含まれる行を全てチェックする
PostgreSQLでは検索条件として、先頭の文字列であれば使うことができる
