Deployment 使用web
Kubernetes提供了一种更加简单的更新RC和Pod的机制,叫作Deployment。经过在Deployment中描述你所指望的集群状态,Deployment Controller会将如今的集群状态在一个可控的速度下逐步更新成你所指望的集群状态。Deployment主要职责一样是为了保证pod的数量和健康,90%的功能与Replication Controller彻底同样,能够看作新一代的Replication Controller。可是,它又具有了Replication Controller以外的新特性:Replication Controller所有功能:Deployment继承了上面描述的Replication Controller所有功能。数据库
#建立命令:kubectl create -f deployment.yaml --record #使用rollout history命令,查看Deployment的历史信息:kubectl rollout history deployment cango-demo #使用rollout undo回滚到上一版本: kubectl rollout undo deployment cango-demo #使用–to-revision能够回滚到指定版本: kubectl rollout undo deployment hello-deployment --to-revision=2
ConfigMap 配置api
在几乎全部的应用开发中,都会涉及到配置文件的变动,好比说在web的程序中,须要链接数据库,缓存甚至是队列等等。
一些大公司专门开发了本身的一套配置管理中心,kubernetes也提供了本身的一套方案,即ConfigMap。kubernetes经过ConfigMap来实现对容器中应用的配置管理。缓存
apiVersion: v1 #接口版本 kind: ConfigMap #接口类型 metadata: name: special-config #Config名称 namespace: cango-prd #命名空间 data: #键值对 special.how: very special.type: charm apiVersion: v1 kind: ConfigMap metadata: name: example-volume-config namespace: cango-prd data: backup-script: | xxxx自定义文件内容 log-script: | xxxx自定义文件内容
StorageClass bash
Kubernetes 集群存储 PV 支持 Static 静态配置以及 Dynamic 动态配置,动态卷配置 (Dynamic provisioning) 能够根据须要动态的建立存储卷。服务器
Example: 定义Ceph做为PV存储池进行分配,每一个云或存储厂商品牌配置参数都不同,可是调用方式都是一致的app
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rbd provisioner: kubernetes.io/rbd parameters: monitors: 10.142.21.21:6789,10.142.21.22:6789,10.142.21.23:6789 adminId: admin adminSecretName: ceph-secret-admin adminSecretNamespace: kube-system pool: rbd userId: admin userSecretName: ceph-secret-admin fsType: ext4 imageFormat: "1"
#建立从StorageClass的关联的Ceph PV存储rdb中申请一块1G大小的PVC命名为rdb-pvc1url
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: rbd-pvc1 namespace: kube-system spec: storageClassName: rbd accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
Deployment部署文件详解spa
apiVersion: extensions/v1beta1 #接口版本 kind: Deployment #接口类型 metadata: name: cango-demo #Deployment名称 namespace: cango-prd #命名空间 labels: app: cango-demo #标签 spec: replicas: 3 strategy: rollingUpdate: ##因为replicas为3,则整个升级,pod个数在2-4个之间 maxSurge: 1 #滚动升级时会先启动1个pod maxUnavailable: 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: 8080 scheme: HTTP initialDelaySeconds: 60 ##启动后延时多久开始运行检测 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 readinessProbe: readinessProbe: httpGet: path: /health #若是没有心跳检测接口就为/ port: 8080 scheme: HTTP initialDelaySeconds: 30 ##启动后延时多久开始运行检测 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 resources: ##CPU内存限制 requests: cpu: 2 memory: 2048Mi limits: cpu: 2 memory: 2048Mi env: ##经过环境变量的方式,直接传递pod=自定义Linux OS环境变量 - name: LOCAL_KEY #本地Key value: value - name: CONFIG_MAP_KEY #局策略可以使用configMap的配置Key, valueFrom: configMapKeyRef: name: special-config #configmap中找到name为special-config key: special.type #找到name为special-config里data下的key ports: - name: http containerPort: 8080 #对service暴露端口 volumeMounts: #挂载volumes中定义的磁盘 - name: log-cache mount: /tmp/log - name: sdb #普通用法,该卷跟随容器销毁,挂载一个目录 mountPath: /data/media - name: nfs-client-root #直接挂载硬盘方法,如挂载下面的nfs目录到/mnt/nfs mountPath: /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-cache emptyDir: {} - 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中的Key path: path/to/log-script #指定目录下的一个相对路径path/to/log-script - key: backup-script #ConfigMap中的Key path: 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磁盘
参考文献:命令行
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://www.jianshu.com/p/6bc8e0ae65d1
http://ju.outofmemory.cn/entry/208362