kubectl技巧之檢視資源列表,資源版本和資源schema配置
阿新 • • 發佈：2019-06-18
系列目錄
在kubernetes裡,pod,service,rs,rc,deploy,resource等物件都需要使用yaml檔案來建立,很多時候我們都是參照照官方示例或者一些第三方示例來編寫yaml檔案以建立物件.雖然這些示例很有典型性和代表性,能夠滿足我們大部分時候的需求,然而這往往還是不夠的,根據專案不同,實際配置可能遠比官方提供的demo配置複雜的多,這就要求我們除了掌握常用的配置外,還需要對其它配置有所瞭解.如果有一個文件能夠速查某一物件的所有配置,不但方便我們學習不同的配置,也可以做為一個小手冊以便我們記不起來某些配置時可以速查.
下面我們介紹一些小技巧來快速檢視kubernetes api
檢視所有api資源
可以通過命令kubectl api-resources來檢視所有api資源
[centos@k8s-master ~]$ kubectl api-resources NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding componentstatuses cs false ComponentStatus configmaps cm true ConfigMap endpoints ep true Endpoints events ev true Event limitranges limits true LimitRange namespaces ns false Namespace nodes no false Node persistentvolumeclaims pvc true PersistentVolumeClaim persistentvolumes pv false PersistentVolume pods po true Pod podtemplates true PodTemplate replicationcontrollers rc true ReplicationController resourcequotas quota true ResourceQuota secrets true Secret serviceaccounts sa true ServiceAccount services svc true Service mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition apiservices apiregistration.k8s.io false APIService controllerrevisions apps true ControllerRevision daemonsets ds apps true DaemonSet deployments deploy apps true Deployment replicasets rs apps true ReplicaSet statefulsets sts apps true StatefulSet tokenreviews authentication.k8s.io false TokenReview localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview subjectaccessreviews authorization.k8s.io false SubjectAccessReview horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler cronjobs cj batch true CronJob jobs batch true Job certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest leases coordination.k8s.io true Lease events ev events.k8s.io true Event daemonsets ds extensions true DaemonSet deployments deploy extensions true Deployment ingresses ing extensions true Ingress networkpolicies netpol extensions true NetworkPolicy podsecuritypolicies psp extensions false PodSecurityPolicy replicasets rs extensions true ReplicaSet networkpolicies netpol networking.k8s.io true NetworkPolicy poddisruptionbudgets pdb policy true PodDisruptionBudget podsecuritypolicies psp policy false PodSecurityPolicy clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding clusterroles rbac.authorization.k8s.io false ClusterRole rolebindings rbac.authorization.k8s.io true RoleBinding roles rbac.authorization.k8s.io true Role priorityclasses pc scheduling.k8s.io false PriorityClass storageclasses sc storage.k8s.io false StorageClass volumeattachments storage.k8s.io false VolumeAttachment
除了可以看到資源的物件名稱外,還可以看到物件的別名,這時候我們再看到別人的命令如kubectl get no這樣費解的命令時就可以知道它實際上代表的是kubectl get nodes命令
檢視api的版本,很多yaml配置裡都需要指定配置的資源版本,我們經常看到v1,beta1,beta2這樣的配置,到底某個資源的最新版本是什麼呢?
其實,可以通過kubectl api-versions來檢視api的版本
[centos@k8s-master ~]$ kubectl api-versions admissionregistration.k8s.io/v1beta1 apiextensions.k8s.io/v1beta1 apiregistration.k8s.io/v1 apiregistration.k8s.io/v1beta1 apps/v1 apps/v1beta1 apps/v1beta2 authentication.k8s.io/v1 authentication.k8s.io/v1beta1 authorization.k8s.io/v1 authorization.k8s.io/v1beta1 autoscaling/v1 autoscaling/v2beta1 autoscaling/v2beta2 batch/v1 batch/v1beta1 certificates.k8s.io/v1beta1 coordination.k8s.io/v1beta1 events.k8s.io/v1beta1 extensions/v1beta1 networking.k8s.io/v1 policy/v1beta1 rbac.authorization.k8s.io/v1 rbac.authorization.k8s.io/v1beta1 scheduling.k8s.io/v1beta1 storage.k8s.io/v1 storage.k8s.io/v1beta1 v1
以上只是整體概況,很多時候我們還想要看到某個api下面都有哪些配置,某一薦配置的含義等,下面羅列一些常用的api範例和一些檢視api的技巧
常見範例
Replica Sets
Replication Controller
Deployment
Service
通過kubectl explain檢視api欄位
1) 通過kubectl explain <資源名物件名>檢視資源物件擁有的欄位
前面說過,可以通過kubectl api-resources來檢視資源名稱,如果想要檢視某個資源的欄位,可以通過kubectl explain <資源名物件名>來查點它都有哪些欄位
[centos@k8s-master ~]$ kubectl explain pod
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>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
status <Object>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
[centos@k8s-master ~]$
以上Description是對資源物件的簡要描述,Fields則是對所有欄位的描述
2) 列出所有api欄位
通過以上我們能感覺到,以上好像並沒有羅列出所有的api欄位,實際上以上列出的僅是一級欄位,一級欄位可能還包含二級的,三級的欄位,想要羅列出所有的欄位,可以加上
--recursive來列出所有可能的欄位
[centos@k8s-master ~]$ kubectl explain svc --recursive
KIND: Service
VERSION: v1
DESCRIPTION:
Service is a named abstraction of software service (for example, mysql)
consisting of local port (for example 3306) that the proxy listens on, and
the selector that determines which pods will answer requests sent through
the proxy.
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>
initializers <Object>
pending <[]Object>
name <string>
result <Object>
apiVersion <string>
code <integer>
details <Object>
causes <[]Object>
field <string>
message <string>
reason <string>
group <string>
kind <string>
name <string>
retryAfterSeconds <integer>
uid <string>
kind <string>
message <string>
metadata <Object>
continue <string>
resourceVersion <string>
selfLink <string>
reason <string>
status <string>
labels <map[string]string>
name <string>
namespace <string>
ownerReferences <[]Object>
apiVersion <string>
blockOwnerDeletion <boolean>
controller <boolean>
kind <string>
name <string>
uid <string>
resourceVersion <string>
selfLink <string>
uid <string>
spec <Object>
clusterIP <string>
externalIPs <[]string>
externalName <string>
externalTrafficPolicy <string>
healthCheckNodePort <integer>
loadBalancerIP <string>
loadBalancerSourceRanges <[]string>
ports <[]Object>
name <string>
nodePort <integer>
port <integer>
protocol <string>
targetPort <string>
publishNotReadyAddresses <boolean>
selector <map[string]string>
sessionAffinity <string>
sessionAffinityConfig <Object>
clientIP <Object>
timeoutSeconds <integer>
type <string>
status <Object>
loadBalancer <Object>
ingress <[]Object>
hostname <string>
ip <string>
[centos@k8s-master ~]$
以上輸出的內容是經過格式化了的,我們可以根據縮排很容易看到某一個欄位從屬於關係
檢視具體欄位
通過上面kubectl explain service --recursive可以看到所有的api名稱,但是以上僅僅是羅列了所有的api名稱,如果想要知道某一個api名稱的詳細資訊,則可以通過kubectl explain <資源物件名稱.api名稱>的方式來檢視,比如以下示例可以檢視到service下的spec下的ports欄位的資訊
[centos@k8s-master ~]$ kubectl explain svc.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:
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. This maps to the 'Name'
field in EndpointPort objects. 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=NodePort
or LoadBalancer. Usually assigned by the system. If specified, it will be
allocated to the service if unused or else creation of the service will
fail. Default is to auto-allocate a port if the ServiceType of this Service
requires one. 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