Kubernetes has a schema that is defined using a verify configuration format; schema can be generated after the first instance of running the subcommand create with a configuration file. The cached schema will be stored under the .kube/cache/discovery/<SERVICE_IP>_<PORT>, based on the version of API server you run:

// create the resource by either YAML or JSON file introduced before
$ kubectl create -f nginx-pod.yaml
// or
$ kubectl create -f nginx-pod.json
// as an example of v1.10.0, the content of schema directory may look like following
// you would have different endpoint of server
ll ~/.kube/cache/discovery/192.168.99.100_8443/
total 76
drwxr-xr-x 18 nosus nosus 4096 May 6 10:10 ./
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 ../
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 admissionregistration.k8s.io/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 apiextensions.k8s.io/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 apiregistration.k8s.io/
drwxr-xr-x 5 nosus nosus 4096 May 6 10:00 apps/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 authentication.k8s.io/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 authorization.k8s.io/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 autoscaling/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 batch/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 certificates.k8s.io/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 events.k8s.io/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 extensions/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 networking.k8s.io/
drwxr-xr-x 3 nosus nosus 4096 May 6 10:00 policy/
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 rbac.authorization.k8s.io/
-rwxr-xr-x 1 nosus nosus 3898 May 6 10:10 servergroups.json*
drwxr-xr-x 4 nosus nosus 4096 May 6 10:00 storage.k8s.io/
drwxr-xr-x 2 nosus nosus 4096 May 6 10:10 v1/

Each directory listed represents an API category. You will see a file named serverresources.json under the last layer of each directory, which clearly defines every resource covered by this API category. However, there are some alternative and easier ways to check the schema. From the website of Kubernetes, we can get any details of how to write a configuration file of specific resources. Go ahead and check the official API documentation of the latest version: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/. In the webpage, there are three panels: from left to right, they are the resource list, description, and the input and output of HTTP requests or the command kubectl. Taking Deployment as an example, you may click Deployment v1 app at the resource list, the leftmost panel, and the following screenshot will show up:

But, how do we know the details of setting the container part at the marked place on the preceding image? In the field part of object description, there are two values. The first one, like apiVersion, means the name, and the second one, like string, is the type. Type could be integer, string, array, or the other resource object. Therefore, for searching the containers configuration of deployment, we need to know the structure of layers of objects. First, according to the example configuration file on web page, the layer of objects to containers is spec.template.spec.containers. So, start by clicking the hyperlink spec DeploymentSpec under Deployment's fields, which is the type of resource object, and go searching hierarchically. Finally, you can find the details listed on this page: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#container-v1-core.

Taking a careful look at the definition of container configuration. The following are some common descriptions you should pay attention to:

• Type: The user should always set the corresponding type for an item.
• Optional or not: Some items are indicated as optional, which means not necessary, and can be applied as a default value, or not set if you don't specify it.
• Cannot be updated: If the item is indicated as failed to be updated, it is fixed when the resource is created. You need to recreate a new one instead of updating it.
• Read-only: Some of the items are indicated as read-only, such as UID. Kubernetes generates these items. If you specify this in the configuration file, it will be ignored.

Another method for checking the schema is through swagger UI. Kubernetes uses swagger (https://swagger.io/) and OpenAPI (https://www.openapis.org) to generate the REST API. Nevertheless, the web console for swagger is by default disabled in the API server. To enable the swagger UI of your own Kubernetes API server, just add the flag --enable-swagger-ui=ture when you start the API server. Then, by accessing the endpoint https://<KUBERNETES_MASTER>:<API_SERVER_PORT>/swagger-ui, you can successfully browse the API document through the web console: