Basic Pod example:

apiVersion: v1      # api to use / compatibility
kind: Pod           # kind of object
metadata:           # descriptive information for management
  name: todo-app    # name of the object
spec:               # specification of object
  containers:       # the container of this pod
  - name: todo-app  # name of the container
    image: letsbootch/todo-app:latest # image to run

Configuration requests are sent to the api application running on the master node in a cluster. These could be sent from a webui, cli app like kubctl, or any other tool that uses the api. The format can be either yaml or json. Here's an example of a simple webapp deployment and service config in yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-deployment
  labels:
    app: webapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: nanajanashia/k8s-demo-app:v1.0
        ports:
        - containerPort: 3000
        env:
        - name: USER_NAME
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: mongo-user
        - name: USER_PWD
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: mongo-password
        - name: DB_URL
          valueFrom:
            configMapKeyRef:
              name: mongo-config
              key: mongo-url
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  type: NodePort
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
      nodePort: 30100

Every configuration file in kubernetes begins by declaring what kind of component it is and an api version. The rest of the config consists of 3 parts:

• metadata
• specs (the types of attributes are determines by the kind of component)
• status (automatically generated and added by kubernetes)

While running the config, kubernetes generates the status and continuously compares it with the specs making any changes needed for compliance. All of this data is stored in the etcd master process.