全般的なAPIの規則は、API規則ドキュメントに記載されています。
APIエンドポイント、リソースタイプ、そしてサンプルはAPIリファレンスに記載されています。
APIへの外部からのアクセスは、APIアクセス制御ドキュメントに記載されています。
Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。kubectlコマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することが出来ます。
また、Kubernetesは、シリアライズされた状態を(現在はetcdに)APIリソースの単位で保存しています。
Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。
我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、API廃止ポリシーへの準拠を必要とします。
何が互換性のある変更を意味するか、またAPIをどのように変更するかは、API変更ドキュメントに詳解されています。
完全なAPIの詳細は、OpenAPIに記載されています。
Kubernetes 1.10から、KubernetesAPIサーバーは/openapi/v2のエンドポイントを通じて、OpenAPI仕様を提供しています。
リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます:
| ヘッダ | 設定可能な値 |
|---|---|
| Accept | application/json, application/com.github.proto-openapi.spec.v2@v1.0+protobuf (デフォルトのcontent-typeは、*/*に対してapplication/jsonか、もしくはこのヘッダーを送信しません) |
| Accept-Encoding | gzip (このヘッダーを送信しないことも許容されています) |
1.14より前のバージョンでは、フォーマット分離エンドポイント(/swagger.json, /swagger-2.0.0.json, /swagger-2.0.0.pb-v1, /swagger-2.0.0.pb-v1.gz)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
OpenAPI仕様の取得サンプル:
| 1.10より前 | Kubernetes1.10以降 |
|---|---|
| GET /swagger.json | GET /openapi/v2 Accept: application/json |
| GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf |
| GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf Accept-Encoding: gzip |
Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要はデザイン提案に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
また、1.14より前のバージョンのKubernetesAPIサーバーでは、Swagger v1.2をベースにしたKubernetes仕様を、/swaggerapiで公開しています。
このエンドポイントは非推奨となっており、Kubernetes1.14で削除される予定です。
フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、/api/v1や/apis/extensions/v1beta1のように、それぞれ異なるAPIのパスが割り当てられています。
APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。
APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。APIとリリースバージョニング提案で、APIとソフトウェアのバージョニングの関連について記載しています。
異なるバージョンのAPIは、異なるレベル(版)の安定性とサポートを持っています。それぞれのレベル(版)の基準は、API変更ドキュメントに詳細が記載されています。下記に簡潔にまとめます:
alphaを含みます(例、v1alpha1)。betaを含みます(例、v2beta3)。vXのようになっており、Xは整数です。KubernetesAPIの拡張を簡易に行えるようにするため、APIグループを実装しました。
APIグループは、RESTのパスとシリアライズされたオブジェクトのapiVersionフィールドで指定されます。
現在、いくつかのAPIグループが利用されています:
core グループ(度々、legacy group と呼ばれます)は、/api/v1というRESTのパスで、apiVersion: v1を使います。
名前付きのグループは、/apis/$GROUP_NAME/$VERSIONというRESTのパスで、apiVersion: $GROUP_NAME/$VERSION(例、apiVersion: batch/v1)を使います。サポートされているAPIグループの全リストは、Kubernetes APIリファレンスを参照してください。
カスタムリソースでAPIを拡張するために、2つの方法がサポートされています:
いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの--runtime-config設定で、有効化、無効化できます。--runtime-configは、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、--runtime-config=batch/v1=falseをセットし、batch/v2alpha1を有効化する場合、--runtime-config=batch/v2alpha1をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
重要: APIグループ、リソースの有効化、無効化は、--runtime-configの変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。
DaemonSets、Deployments、HorizontalPodAutoscalers、Ingresses、JobsReplicaSets、そしてReplicaSetsはデフォルトで有効です。
その他の拡張リソースは、APIサーバーの--runtime-configを設定することで有効化できます。--runtime-configはカンマ区切りの複数の値を設定可能です。例えば、deploymentsとingressを無効化する場合、--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=falseと設定します。
このページは役に立ちましたか?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to 問題を報告する or 改善を提案.