k8s各类yaml文件

(1) deployment.yaml文件详解

apiVersion: extensions/v1beta1   #接口版本
kind: Deployment                 #接口类型
metadata:name: cango-demo               #Deployment名称namespace: cango-prd           #命名空间labels:app: cango-demo              #标签
spec:replicas: 3strategy:rollingUpdate:  ##由于replicas为3,则整个升级,pod个数在2-4个之间maxSurge: 1      #滚动升级时会先启动1个podmaxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数template:         metadata:labels:app: cango-demo  #模板名称必填sepc: #定义容器模板，该模板可以包含多个容器containers:                                                                   - name: cango-demo                                                           #镜像名称image: swr.cn-east-2.myhuaweicloud.com/cango-prd/cango-demo:0.0.1-SNAPSHOT #镜像地址command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ]    #启动命令args:                                                                #启动参数- '-storage.local.retention=$(STORAGE_RETENTION)'- '-storage.local.memory-chunks=$(STORAGE_MEMORY_CHUNKS)'- '-config.file=/etc/prometheus/prometheus.yml'- '-alertmanager.url=http://alertmanager:9093/alertmanager'- '-web.external-url=$(EXTERNAL_URL)'#如果command和args均没有写，那么用Docker默认的配置。#如果command写了，但args没有写，那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command（不带任何参数的）。#如果command没写，但args写了，那么Docker默认配置的ENTRYPOINT的命令行会被执行，但是调用的参数是.yaml中的args。#如果如果command和args都写了，那么Docker默认的配置被忽略，使用.yaml的配置。imagePullPolicy: IfNotPresent  #如果不存在则拉取livenessProbe:       #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；httpGet:path: /health #如果没有心跳检测接口就为/port: 8080scheme: HTTPinitialDelaySeconds: 60 ##启动后延时多久开始运行检测timeoutSeconds: 5successThreshold: 1failureThreshold: 5readinessProbe:httpGet:path: /health #如果没有心跳检测接口就为/port: 8080scheme: HTTPinitialDelaySeconds: 30 ##启动后延时多久开始运行检测timeoutSeconds: 5successThreshold: 1failureThreshold: 5resources:              ##CPU内存限制requests:cpu: 2memory: 2048Milimits:cpu: 2memory: 2048Mienv:                    ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量- name: LOCAL_KEY     #本地Keyvalue: value- name: CONFIG_MAP_KEY  #局策略可使用configMap的配置Key，valueFrom:configMapKeyRef:name: special-config   #configmap中找到name为special-configkey: special.type      #找到name为special-config里data下的keyports:- name: httpcontainerPort: 8080 #对service暴露端口volumeMounts:     #挂载volumes中定义的磁盘- name: log-cachemount: /tmp/log- name: sdb       #普通用法，该卷跟随容器销毁，挂载一个目录mountPath: /data/media    - name: nfs-client-root    #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfsmountPath: /mnt/nfs- name: example-volume-config  #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。mountPath: /etc/config       - name: rbd-pvc                #高级用法第2中，挂载PVC(PresistentVolumeClaim)#使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，volumes:  # 定义磁盘给上面volumeMounts挂载- name: log-cacheemptyDir: {}- name: sdb  #挂载宿主机上面的目录hostPath:path: /any/path/it/will/be/replaced- name: example-volume-config  # 供ConfigMap文件内容到指定路径使用configMap:name: example-volume-config  #ConfigMap中名称items:- key: log-script           #ConfigMap中的Keypath: path/to/log-script  #指定目录下的一个相对路径path/to/log-script- key: backup-script        #ConfigMap中的Keypath: path/to/backup-script  #指定目录下的一个相对路径path/to/backup-script- name: nfs-client-root         #供挂载NFS存储类型nfs:server: 10.42.0.55          #NFS服务器地址path: /opt/public           #showmount -e 看一下路径- name: rbd-pvc                 #挂载PVC磁盘persistentVolumeClaim:claimName: rbd-pvc1         #挂载已经申请的pvc磁盘
Pod yaml文件详解
# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据name: string       #必选，Pod名称namespace: string    #必选，Pod所属的命名空间labels:      #自定义标签- name: string     #自定义标签名字annotations:       #自定义注释列表- name: string
spec:         #必选，Pod中容器的详细定义containers:      #必选，Pod中容器列表- name: string     #必选，容器名称image: string    #必选，容器的镜像名称imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令args: [string]     #容器的启动命令参数列表workingDir: string     #容器的工作目录volumeMounts:    #挂载到容器内部的存储卷配置- name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符readOnly: boolean    #是否为只读模式ports:       #需要暴露的端口库号列表- name: string     #端口号名称containerPort: int   #容器需要监听的端口号hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同protocol: string     #端口协议，支持TCP和UDP，默认TCPenv:       #容器运行前需设置的环境变量列表- name: string     #环境变量名称value: string    #环境变量的值resources:       #资源限制和请求的设置limits:      #资源限制的设置cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数requests:      #资源请求的设置cpu: string    #Cpu请求，容器启动的初始可用数量memory: string     #内存清楚，容器启动的初始可用数量livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可exec:      #对Pod容器内检查方式设置为exec方式command: [string]  #exec方式需要制定的命令或脚本httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式port: numberinitialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged:falserestartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该PodnodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定- name: stringhostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络volumes:       #在该pod上定义共享存储卷列表- name: string     #共享存储卷名称 （volumes类型有很多种）emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部scretname: string  items:     - key: stringpath: stringconfigMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部name: stringitems:- key: stringpath: string

(2) Pod yaml文件详解

# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据name: string       #必选，Pod名称namespace: string    #必选，Pod所属的命名空间labels:      #自定义标签- name: string     #自定义标签名字annotations:       #自定义注释列表- name: string
spec:         #必选，Pod中容器的详细定义containers:      #必选，Pod中容器列表- name: string     #必选，容器名称image: string    #必选，容器的镜像名称imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令args: [string]     #容器的启动命令参数列表workingDir: string     #容器的工作目录volumeMounts:    #挂载到容器内部的存储卷配置- name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符readOnly: boolean    #是否为只读模式ports:       #需要暴露的端口库号列表- name: string     #端口号名称containerPort: int   #容器需要监听的端口号hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同protocol: string     #端口协议，支持TCP和UDP，默认TCPenv:       #容器运行前需设置的环境变量列表- name: string     #环境变量名称value: string    #环境变量的值resources:       #资源限制和请求的设置limits:      #资源限制的设置cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数requests:      #资源请求的设置cpu: string    #Cpu请求，容器启动的初始可用数量memory: string     #内存清楚，容器启动的初始可用数量livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可exec:      #对Pod容器内检查方式设置为exec方式command: [string]  #exec方式需要制定的命令或脚本httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式port: numberinitialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged:falserestartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该PodnodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定- name: stringhostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络volumes:       #在该pod上定义共享存储卷列表- name: string     #共享存储卷名称 （volumes类型有很多种）emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部scretname: string  items:     - key: stringpath: stringconfigMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部name: stringitems:- key: stringpath: string

(3) Service yaml文件详解

apiVersion: v1
kind: Service
matadata:                                #元数据name: string                           #service的名称namespace: string                      #命名空间  labels:                                #自定义标签属性列表- name: stringannotations:                           #自定义注解属性列表  - name: string
spec:                                    #详细描述selector: []                           #label selector配置，将选择具有label标签的Pod作为管理 #范围type: string                           #service的类型，指定service的访问方式，默认为 #clusterIpclusterIP: string                      #虚拟服务地址      sessionAffinity: string                #是否支持sessionports:                                 #service需要暴露的端口列表- name: string                         #端口名称protocol: string                     #端口协议，支持TCP和UDP，默认TCPport: int                            #服务监听的端口号targetPort: int                      #需要转发到后端Pod的端口号nodePort: int                        #当type = NodePort时，指定映射到物理机的端口号status:                                #当spce.type=LoadBalancer时，设置外部负载均衡器的地址loadBalancer:                        #外部负载均衡器    ingress:                           #外部负载均衡器 ip: string                       #外部负载均衡器的Ip地址值hostname: string                 #外部负载均衡器的主机名

目前kubernetes提供了两种负载分发策略：RoundRobin和SessionAffinity

RoundRobin：轮询模式，即轮询将请求转发到后端的各个Pod上

SessionAffinity：基于客户端IP地址进行会话保持的模式，第一次客户端访问后端某个Pod，之后的请求都转发到这个Pod上

默认是RoundRobin模式

在某些场景中，开发人员希望自己控制负载均衡的策略，不使用Service提供的默认负载，kubernetes通过Headless Service的概念来实现。不给Service设置ClusterIP（无入口IP地址）：

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80clusterIP: Noneselector:app: nginx

有时候，一个容器应用提供多个端口服务：

apiVersion: v1
kind: Service
metadata:name: webapp
spec:ports:- port: 8080targetPort: 8080name: web- port: 8005targetPort: 8005name: managementselector:app: webapp

为不同的应用分配各自的端口。

另一个例子是两个端口使用了不同的4层协议，即TCP或UDP

apiVersion: v1
kind: Service
metadata:name: kube-dnsnamespace: kube-systemlabels:k8s-app: kube-dnskubernetes.io/cluster-service: "true"kubernetes.io/name: "KubeDNS"
spec:selector:k8s-app: kube-dnsclusterIP: 169.169.0.100ports:- name: dnsport: 53protocol: UDP- name: dns-tcpport: 53protocol: TCP

集群外部访问Pod或Service
为了让外部客户端可以访问这些服务，可以将Pod或者Service的端口号映射到宿主主机，使得客户端应用能够通过物理机访问容器应用。

将容器应用的端口号映射到物理机
通过设置容器级别的hostPort，将容器应用的端口号映射到物理机上：

pod-hostport.yaml：

apiVersion: v1
kind: Pod
metadata:name: webapplabels:app: webapp
spec:containers:- name: webappimage: tomcatports:- containerPort: 8080hostPort:8081

创建这个Pod：

kubectl create -f pod-hostnetwork.yaml

通过物理机的IP地址和8080端口访问Pod的容器服务：

curl 10.0.11.151:8080

将Service的端口号映射到物理机

通过设置nodePort映射到物理机，同时设置Service的类型为NodePort：

webapp-svc-nodeport.yaml：

apiVersion: v1
kind: Service
metadata:name: webapp
spec:type: NodePortports:- port: 8080targetPort: 8080nodePort: 8081selector:app: webapp

创建这个Service：

kubectl create -f webapp-svc-nodeport.yaml

通过物理机的IP和端口访问：

curl 10.0.11.151:8081

(4) ingress.yaml详解

通常情况下，service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。从概念上讲，可能像下面这样：

  internet|------------[ Services ]

Ingress是授权入站连接到达集群服务的规则集合。

internet|[ Ingress ]--|-----|--[ Services ]

你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress，通常使用负载平衡器，它还可以配置边界路由和其他前端，这有助于以HA方式处理流量。

Ingress Resource

最简化的Ingress配置：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: test-ingress
spec:                                # Ingress spec 中包含配置一个loadbalancer或proxy serverrules:                             # 的所有信息。最重要的是，它包含了一个匹配所有入站请求的规- http:                            # 则列表。目前ingress只支持http规则。paths:- path: /testpath              # 每条http规则包含以下信息：一个host配置项（比如 # for.bar.com，在这个例子中默认是*），path列表（比 # 如：/testpath），每个path都关联一个backend(比如 # test:80)。在loadbalancer将流量转发到backend之前，所有的 # 入站请求都要先匹配host和path。backend:                        serviceName: test          # backend是一个service:port的组合。Ingress的流量被转发到                        servicePort: 80            #  它所匹配的backend

Ingress类型

Kubernetes中已经存在一些概念可以暴露单个service，但是你仍然可以通过Ingress来实现，通过指定一个没有rule的默认backend的方式。

ingress.yaml定义文件：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: test-ingress
spec:backend:serviceName: testsvcservicePort: 80

使用kubectl create -f命令创建，然后查看ingress：

$ kubectl get ing
NAME                RULE          BACKEND        ADDRESS
test-ingress        -             testsvc:80     107.178.254.228

107.178.254.228就是Ingress controller为了实现Ingress而分配的IP地址。RULE列表示所有发送给该IP的流量都被转发到了BACKEND所列的Kubernetes service上。

简单展开

如前面描述的那样，kubernete pod中的IP只在集群网络内部可见，我们需要在边界设置一个东西，让它能够接收ingress的流量并将它们转发到正确的端点上。这个东西一般是高可用的loadbalancer。使用Ingress能够允许你将loadbalancer的个数降低到最少，例如，假如你想要创建这样的一个设置：

foo.bar.com -> 178.91.123.132 -> / foo    s1:80/ bar    s2:80

你需要一个这样的ingress：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: test
spec:rules:- host: foo.bar.comhttp:paths:- path: /foobackend:serviceName: s1servicePort: 80- path: /barbackend:serviceName: s2servicePort: 80

使用kubectl create -f创建完ingress后：

$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS
test      -foo.bar.com/foo          s1:80/bar          s2:80

只要服务（s1，s2）存在，Ingress controller就会将提供一个满足该Ingress的特定loadbalancer实现。这一步完成后，您将在Ingress的最后一列看到loadbalancer的地址。

基于名称的虚拟主机

Name-based的虚拟主机在同一个IP地址下拥有多个主机名。

foo.bar.com --|                 |-> foo.bar.com s1:80| 178.91.123.132  |
bar.foo.com --|                 |-> bar.foo.com s2:80

下面这个ingress说明基于Host header的后端loadbalancer的路由请求：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: test
spec:rules:- host: foo.bar.comhttp:paths:- backend:serviceName: s1servicePort: 80- host: bar.foo.comhttp:paths:- backend:serviceName: s2servicePort: 80

默认backend：一个没有rule的ingress，如前面章节中所示，所有流量都将发送到一个默认backend。你可以用该技巧通知loadbalancer如何找到你网站的404页面，通过制定一些列rule和一个默认backend的方式。如果请求header中的host不能跟ingress中的host匹配，并且/或请求的URL不能与任何一个path匹配，则流量将路由到你的默认backend。

参考：

Kubernetes Ingress解析