目录

一、理论

1.Kubernetes与yaml文件

二、实验

1.Kubernetes与yaml文件

三、问题

1.kubectl create 和 kubectl apply区别

四、总结

---

一、理论

1.​​​​​​​Kubernetes与yaml文件

（1）Kubernetes支持管理资源对象的文件格式

Kubernetes支持YAML 和JSON 格式管理资源对象

JSON格式:主要用于api 接口之间消息的传递

YAML格式:用于配置和管理，YAML是一种简洁的非标记性语言，内容格式人性化，较易读

（2）YAML语法格式

●大小写敏感

●使用缩进表示层级关系

●不支持Tab键制表符缩进，只使用空格缩进

●缩进的空格数目不重要，只要相同层级的元素左侧对齐即可，通常开头缩进两个空格:

●字符后缩进一 个空格，如冒号，逗号，短横杆(-)等

●"—"表示YAML格式， 一个文件的开始，用于分隔文件间

●“#"表示注释

（3）查看api资源版本标签

kubectl api-versions

Which Kubernetes apiVersion Should I Use? - Kubernetes Book

版本如下：

alpha
名称中带有alpha的API版本是进入Kubernetes的新功能的早期候选版本。这些可能包含错误，并且不保证将来可以使用。

beta
API版本名称中的beta表示测试已经超过了alpha级别，并且该功能最终将包含在Kubernetes中。 虽然它的工作方式可能会改变，并且对象的定义方式可能会完全改变，但该特征本身很可能以某种形式将其变为Kubernetes。

stable
稳定的apiVersion这些名称中不包含alpha或beta。 它们可以安全使用。

v1
这是Kubernetes API的第一个稳定版本。 它包含许多核心对象。

apps/v1
apps是Kubernetes中最常见的API组，其中包含许多核心对象和v1。 它包括与在Kubernetes上运行应用程序相关的功能，如Deployments，RollingUpdates和ReplicaSets。

autoscaling/v1
此API版本允许根据不同的资源使用指标自动调整容器。此稳定版本仅支持CPU扩展，但未来的alpha和beta版本将允许您根据内存使用情况和自定义指标进行扩展。

batch/v1
batchAPI组包含与批处理和类似作业的任务相关的对象（而不是像应用程序一样的任务，如无限期地运行Web服务器）。 这个apiVersion是这些API对象的第一个稳定版本。

batch/v1beta1
Kubernetes中批处理对象的新功能测试版，特别是包括允许您在特定时间或周期运行作业的CronJobs。

certificates.k8s.io/v1beta1
此API版本添加了验证网络证书的功能，以便在群集中进行安全通信。 您可以在官方文档上内容。

extensions/v1beta1
此版本的API包含许多新的常用Kubernetes功能。 部署，DaemonSets，ReplicaSet和Ingresses都在此版本中收到了重大更改。

policy/v1beta1
此apiVersion增加了设置pod中断预算和pod安全性新规则的功能

rbac.authorization.k8s.io/v1
此apiVersion包含Kubernetes基于角色的访问控制的额外功能。这有助于您保护群集

（4）写一个yaml文件demo

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

创建资源对象

kubectl create -f nginx-deployment.yaml

查看创建的pod资源

kubectl get pods -o wide -n kube-public
 
kubectl get deploy -n kube-public

创建service服务对外提供访问并测试

vim nginx-server.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-demo1
  namespace: kube-public
  labels:
    name: nginx-demo1
spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 80
      nodePort: 31333
  selector:
    app: nginx-demo1

kubectl apply -f nginx-server.yaml
 
kubectl get svc -n kube-public

在浏览器输入 nodeIP: nodePort 即可访问

http://192.168.204.173:31333
http://192.168.204.175:31333

（5）k8s中的port

●port
port是k8s集群内部访问service的端口，即通过clusterIP: port可以从Pod所在的Node. 上访问到service 

●nodePort
nodePort是外部访问k8s集群中service的端口，通过nodeIP: nodePort 可以从外部访问到某个service。

●targetPort
targetPort是Pod的端口，从port或nodePort来的流量经过kube-proxy 反向代理负载均衡转发到后端Pod的targetPort上，最后进入容器。

●containerPort
containerPort是Pod内部容器的端口，targetPort 映射到containerPort

（6）创建yaml文件模板

kubectl run --dry-run 打印相应的API 对象而不执行创建

kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run

查看生成yaml格式

kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o yaml

查看生成json格式

kubectl run nginx-test --image=nginx --port=80 --replicas=3 --dry-run -o json 

使用yaml格式导出生成模板，并进行修改以及删除一些不必要的参数

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

生成镜像并查看

kubectl apply -f nginx-test.yaml
 
kubectl get svc -n kube-public

将现有的资源生成模板导出

kubectl get deployment/nginx-deployment --export -o yaml

保存到文件中

kubectl get deploy/nginx-deployment --export -o yaml > my-deploy.yaml

查看字段帮助信息，可一层层的查看相关资源对象的帮助信息

kubectl explain deployments.spec.template.spec.containers
或
kubectl explain pods.spec.containers

（7）快速编写yaml

用run命令生成

kubectl run my-deploy --image=nginx --dry-run -o yaml > my-deploy.yaml

用get命令导出

kubectl get deploy/nginx-deployment --export -o=yaml > new.yaml

二、实验

1.Kubernetes与yaml文件

（1）查看api资源版本标签

（2） 写一个yaml文件demo

创建资源对象

查看创建的pod资源

创建service服务对外提供访问并测试

在浏览器输入 nodeIP: nodePort 即可访问

http://192.168.204.173:31333
http://192.168.204.175:31333

（2） 创建yaml文件模板

kubectl run --dry-run 打印相应的API 对象而不执行创建

查看生成yaml格式

查看生成json格式

使用yaml格式导出生成模板，并进行修改以及删除一些不必要的参数

生成镜像并查看

将现有的资源生成模板导出

保存到文件中

查看字段帮助信息，可一层层的查看相关资源对象的帮助信息

或

（3）快速编写yaml

 用run命令生成

kubectl run my-deploy --image=nginx --dry-run -o yaml > my-deploy.yaml

用get命令导出

kubectl get deploy/nginx-deployment --export -o=yaml > new.yaml

三、问题

1.kubectl create 和 kubectl apply区别

（1）kubectl create

第 1 次执行 kubectl create -f pod.xml 命令，正常结束，如下：

kubectl create -f pod.xml
pod/my-pod created

第 2 次执行 kubectl create -f pod.xml 命令，抛出错误，如下：

kubectl create -f pod.xml
Error from server (AlreadyExists): error when creating “pod.xml”: pods “my-pod” already exists

（2）kubectl apply

第 1 次执行 kubectl apply -f pod.xml 命令，显示 created，如下：

kubectl apply -f pod.xml
pod/my-pod created

第 2 次执行 kubectl apply -f pod.xml 命令，由于配置没改变，则显示 unchanged ，如下：

kubectl apply -f pod.xml
pod/my-pod unchanged

（3）区别

kubectl create：

1）kubectl create命令，是先删除所有现有的东西，重新根据yaml文件生成新的。所以要求yaml文件中的配置必须是完整的

2）kubectl create命令，用同一个yaml 文件执行替换replace命令，将会不成功，fail掉。

kubectl apply：

  kubectl apply命令，根据配置文件里面列出来的内容，升级现有的。所以yaml文件的内容可以只写需要升级的属性

 

四、总结

yaml文件的学习方法

(1)多看别人(官方)写的，能读懂
(2)能照着现场的文件改着用
(3)遇到不懂的，善用kubectl explain ...命令查