JSON format : mainly used for message transmission between API interfaces
YAML format is used for configuration and management. YAML is a concise, non-markup language. The content format is user-friendly and easier to read.

1. The main differences between YAML and JSON

1. YAML uses spaces for indentation, which is an area familiar to Python developers.

2. JavaScript developers love JSON because it is a subset of JavaScript that can be interpreted and written directly in JavaScript, while declaring JSON in a shorthand way and eliminating the need for double quotes in keys when using typical variable names without spaces.

3. There are many interpreters that work well in all languages of YAML and JSON

4. In many cases, the whitespace format of YAML can be easier to view because formatting requires a more humane approach.

5. If there are no visible spaces or indent line indicators in your editor, then YAML whitespace, while more compact and easier to see, may be difficult to edit manually.

6. Serialization and deserialization of JSON is much faster because there are significantly fewer features to check than YAML, which allows smaller and lighter code to handle JSON

7. A common misconception is that YAML requires less punctuation and is more compact than JSON, but this is completely wrong. The spaces are invisible, so it looks like there are fewer characters, but if you count the actual spaces that are necessary in order for the YAML to be interpreted correctly as well as for proper indentation, you'll find that YAML actually requires more characters than JSON. JSON does not use whitespace to represent hierarchy or grouping, and can be easily flattened by removing unnecessary whitespace for more compact transmission

2. YAML language format

Case Sensitive
Use indentation to indicate hierarchical relationships
Tab key indentation is not supported, only spaces are used for indentation
The number of indented spaces is not important, as long as elements at the same level are aligned to the left, usually two spaces are indented at the beginning.
Indent a space after a symbol character, such as colon, comma, dash (-), etc.
—Indicates YAML format, the beginning of a file, used to separate files
# represents comments

2. YAML

1. Check the API resource version label

kubectl api-versions

2. Prepare resource allocation list

2.1 Write nginx-test.yaml resource configuration file

vim nginx-test.yaml
 
#指定api版本标签
apiVersion: apps/v1
#定义资源的类型/角色，deployment为副本控制器
#此处资源类型可以是Deployment、Job、Ingress、Service等
kind: Deployment
#定义资源的元数据信息，比如资源的名称、namespace、标签等信息
metadata:
#定义资源的名称，在同一个namespace空间中必须是唯一的
  name: nginx-deployment
  labels:
    app: nginx
#定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
spec:
#定义副本数量
  replicas: 3
#定义标签选择器
  selector:
#定义匹配标签
    matchLabels:
#需与后面的.spec.template.metadata.labels定义的标签保持一致
      app: nginx
#定义业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
  template:
    metadata:
#定义Pod副本将使用的标签，需与前面的.spec.selector.matchLabels定义的标签保持一致
      labels:
        app: nginx
    spec:
#定义容器属性
      containers:
#定义一个容器名，一个-name:定义一个容器
      - name: nginx
#定义容器使用的镜像以及版本
        image: nginx:1.15.4
        ports:
#定义容器对外的端口
        - containerPort: 80
 
#------------------------------------------------------------------#
#无注释
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

2.2 Create resource objects

kubectl create -f nginx-test.yaml

2.3 View the created pod resources

kubectl get pods -o wide

3. Create a service service to provide external access and test it

3.1 Write nginx-svc-test.yaml file

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
  selector:
#此处定义的selector要与deployment所定义的selector相同
#service依靠标签选择器来检索提供服务的nodes
    app: nginx

3.2 Create resource objects

kubectl create -f nginx-svc-test.yaml
kubectl get svc

3.3 Access test

3. Detailed explanation of ports in K8s

port

port is the port used to access the service within the K8s cluster, that is, the service can be accessed from the Node where the Pod is located through clusterIP:port.

nodePort

nodePort is the port for external access to the service in the K8s cluster. The service can be accessed from the outside through nodeIP:nodePort.

targetPort

The targetPort is the port of the Pod. Traffic from the port or nodePort is forwarded to the targetPort of the backend Pod through the kube-proxy reverse proxy load balancing, and finally enters the container.

containerPort

containerPort is the port of the container inside the Pod, and targetPort is mapped to containerPort

4. Create an instance after the trial run generates the yaml template.

1. –dry-run: trial run

–dry-run: indicates a trial run without actually executing the command (testing whether the command is correct), that is, the pod and deployment instances will not be actually created. After removing this parameter, the command can be actually executed.

kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run=client
#打印相应的 API 对象而不执行创建

2. View the generated yaml format

Use --dry-run to test run without triggering the generated command, and then use -o yaml to view its yaml resource configuration list

kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml

3. View the generated json format

You can view the json configuration list generated by this command through -o json

kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run=client -o json

4. Use yaml format to export and generate templates

kubectl create deployment dryrun-test --image=nginx --port=80 --replicas=3 --dry-run=client -o yaml > dryrun-test.yaml

5. Create an instance using yaml template

kubectl apply -f dryrun-test.yaml
kubectl get pod,deploy

6. Export and save the yaml template generated from existing resources as a file

kubectl get deploy dryrun-test -o yaml
kubectl get deploy dryrun-test -o yaml > export-test.yaml

7. View field help information

explain can view the help information of related resource objects layer by layer.

kubectl explain deployments.spec.template.spec.containers

kubectl explain pods.spec.containers

[Cloud Native K8s] Detailed explanation of YAML files

1. File formats supported by K8s