はじめに
kubectl
を使ってマニフェストのフォートマットを検索する方法を紹介します。
kubectlでマニフェスト検索
kubectl explain
を使うことによって、マニフェストのフォーマットを検索することができます。
また、--recursive
オプションを入れることで階層的な出力ができます。
全階層取得
特定のリソースのマニフェストのフォーマットを全階層取得する場合は下記になります。
kubectl explain <resource> --recursive
less
コマンドを使ってスクロールしながら確認もできます。
kubectl explain <resource> --recursive | less
検索したい行とその後ろの数行を取得
下記コマンドを使えば、パターンに一致した行とその後ろの数行を出力できます。
kubectl explain <resource> --recursive | grep -A <num> <pattern>
特定のフィールド
特定のフィールドの場合は下記になります。--recursive
オプションを入れないことで、特定のフィールドのより詳細な書き方が出力されます。
kubectl explain <resource>.<field>(.<field>...)
具体例
実際にマニフェストのフォーマットを出力してみます。
Podのマニフェストの全階層を取得してみます。
❯ kubectl explain pod --recursive
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
annotations <map[string]string>
clusterName <string>
creationTimestamp <string>
deletionGracePeriodSeconds <integer>
deletionTimestamp <string>
finalizers <[]string>
generateName <string>
generation <integer>
labels <map[string]string>
:
:
:
DeploymentのenvFrom
フィールドとその下の階層を確認する場合は、下記のようになります。
❯ kubectl explain deployment --recursive | grep -A 5 envFrom
envFrom <[]Object>
configMapRef <Object>
name <string>
optional <boolean>
prefix <string>
secretRef <Object>
--
envFrom <[]Object>
configMapRef <Object>
name <string>
optional <boolean>
prefix <string>
secretRef <Object>
--
envFrom <[]Object>
configMapRef <Object>
name <string>
optional <boolean>
prefix <string>
secretRef <Object>
service.spec.ports
のフィールドの詳細な書き方を取得したい場合は、下記になります。
❯ kubectl explain service.spec.ports
KIND: Service
VERSION: v1
RESOURCE: ports <[]Object>
DESCRIPTION:
The list of ports that are exposed by this service. More info:
https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
ServicePort contains information on service's port.
FIELDS:
appProtocol <string>
The application protocol for this port. This field follows standard
Kubernetes label syntax. Un-prefixed names are reserved for IANA standard
service names (as per RFC-6335 and
http://www.iana.org/assignments/service-names). Non-standard protocols
should use prefixed names such as mycompany.com/my-custom-protocol.
name <string>
The name of this port within the service. This must be a DNS_LABEL. All
ports within a ServiceSpec must have unique names. When considering the
endpoints for a Service, this must match the 'name' field in the
EndpointPort. Optional if only one ServicePort is defined on this service.
nodePort <integer>
The port on each node on which this service is exposed when type is
NodePort or LoadBalancer. Usually assigned by the system. If a value is
specified, in-range, and not in use it will be used, otherwise the
operation will fail. If not specified, a port will be allocated if this
Service requires one. If this field is specified when creating a Service
which does not need it, creation will fail. This field will be wiped when
updating a Service to no longer need it (e.g. changing type from NodePort
to ClusterIP). More info:
https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
port <integer> -required-
The port that will be exposed by this service.
protocol <string>
The IP protocol for this port. Supports "TCP", "UDP", and "SCTP". Default
is TCP.
targetPort <string>
Number or name of the port to access on the pods targeted by the service.
Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If
this is a string, it will be looked up as a named port in the target Pod's
container ports. If this is not specified, the value of the 'port' field is
used (an identity map). This field is ignored for services with
clusterIP=None, and should be omitted or set equal to the 'port' field.
More info:
https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service
まとめ
kubectl explain
でマニフェストのフォーマットが取得できる