The Server Could Not Find the Requested Resource エラーの記事一覧

冒頭まとめ kubectl applyやkubectl getが、次のエラーで止まることがあります。 Error from server (NotFound): the server could not find the requested resource まず、接続先のクラスターが、指定した種類とバージョンのAPIを提供しているかを確認します。APIは、PodやDeploymentなどを作成・取得するための窓口です。マニフェストのapiVersionとkindを控え、現在の接続先とAPI一覧を調べてください。 kubectl config current-context kubectl api-versions kubectl api-resources --cached=false カスタムリソースなら、その種類を追加する定義であるCRD（CustomResourceDefinition）が必要です。CRDを先に適用して登録を待ち、その後にカスタムリソースを適用します。組み込みリソースなら、apiVersionの誤りや、クラスターの更新で提供されなくなった旧APIを確認します。 ただし、この文言だけでCRD不足と断定はできません。404は要求先が見つからなかった応答で、接続先や途中のプロキシが誤っている場合も調査対象になります。 3つのエラー文言の違い 似た状況で次の文言も出ますが、発生する処理は異なります。 文言 示していること the server could not find the requested resource 要求先から404相当の応答を受けた。要求したAPIのパスと応答元を確認する no matches for kind "MyApp" in version "myorg.example.com/v1" kubectl側で、指定したkindとAPIバージョンを対応するAPIへ変換できなかった the server doesn't have a resource type "myapps" kubectl側で、指定したリソース名に対応するAPIを見つけられなかった 最初の文言は、KubernetesのNewGenericServerResponse()がHTTP 404に対応して組み立てるメッセージです。要求した操作、リソースの種類、名前が分かる場合は、末尾に(get deployments.apps my-app)などが付きます。 すべての404がこの固定文言になるわけではありません。 client-goの応答処理は、Kubernetesの形式で返されたエラー情報を利用し、読み取れない応答には汎用的なエラーを作ります。そのため、固定文言だけで、リソースの種類がないのか、個別の名前がないのか、別のサーバーが応答しているのかを決めないでください。 残りの2つは、RESTMapperのエラー定義とkubectlの表示処理に由来します。RESTMapperは、種類やリソース名をAPIの宛先へ対応付ける仕組みです。対象オブジェクトの操作へ進む前に失敗しますが、対応付けに使うAPI一覧をサーバーから取得することがあります。接続を一度も試していないという意味ではありません。 接続先とAPI一覧を確認する 同じマニフェストでも、開発用クラスターにはCRDがあり、本番用にはない場合があります。最初に現在のcontext（接続先の設定）を確認します。 kubectl config current-context kubectl config get-contexts 接続先が正しければ、apiVersionとkindを照合します。たとえばapiVersion: apps/v1、kind: Deploymentなら、次を実行します。 ...