deployment描述相对于pod少了些内容deployment最终是创建pod所以一定有一个地方用来描述如何创建pod而如何创建pod就在spec下面的template字段里面。template下面描述的是pod如何创建跟pod的yaml比起来少了gvknamespacename因为deployment是namespace级别的资源所以他所能管理的pod一定不能超过deployment的namespace不可以跨命名空间去创建资源对象deployment可以指定多副本所以pod就不可能指定name了注意在deployment中spec描述的pod对象的label是一定要写的--必须带有标签创建deployment模板修改现在如果删掉一个pod还是会创建新的如果对deployment里面的pod进行修改然后重新运行那么会启动新的删掉旧的最终变成5个为什么直接创建出来的 Podspec 大部分字段不允许修改可以查看deployment详情如果把deployment删掉那么pod也就删掉了直接删pod是删不掉的。可以在线修改deploymentedit一般是用于临时调试的因为deployment的yaml文件不会修改只要一apply还是恢复成原先的样子。查看deployment运行中的更新策略默认的statefulset 有状态集apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: replicas: 3 selector: matchLabels: app: mysql serviceName: mysql-headless # ✅必须绑定无头Service负责DNS域名解析 template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:8.0 volumeClaimTemplates: # ✅PVC模板StatefulSet特有生成一一对应的PVC - metadata: name: data spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 10Gi updateStrategy: # StatefulSet更新策略和Deployment完全不一样 type: RollingUpdate rollingUpdate: partition: 0没有更新策略因为是串行启动多了serviceNamedaemonsetapiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit spec: selector: matchLabels: app: fluent-bit template: metadata: labels: app: fluent-bit spec: # tolerationsDaemonSet几乎必配容忍度否则不能调度到master节点 tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule containers: - name: fluent-bit image: fluent/fluent-bit:latest updateStrategy: # DaemonSet更新策略 type: RollingUpdate rollingUpdate: maxUnavailable: 1
kbuernets的高级资源对象
deployment描述相对于pod少了些内容deployment最终是创建pod所以一定有一个地方用来描述如何创建pod而如何创建pod就在spec下面的template字段里面。template下面描述的是pod如何创建跟pod的yaml比起来少了gvknamespacename因为deployment是namespace级别的资源所以他所能管理的pod一定不能超过deployment的namespace不可以跨命名空间去创建资源对象deployment可以指定多副本所以pod就不可能指定name了注意在deployment中spec描述的pod对象的label是一定要写的--必须带有标签创建deployment模板修改现在如果删掉一个pod还是会创建新的如果对deployment里面的pod进行修改然后重新运行那么会启动新的删掉旧的最终变成5个为什么直接创建出来的 Podspec 大部分字段不允许修改可以查看deployment详情如果把deployment删掉那么pod也就删掉了直接删pod是删不掉的。可以在线修改deploymentedit一般是用于临时调试的因为deployment的yaml文件不会修改只要一apply还是恢复成原先的样子。查看deployment运行中的更新策略默认的statefulset 有状态集apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: replicas: 3 selector: matchLabels: app: mysql serviceName: mysql-headless # ✅必须绑定无头Service负责DNS域名解析 template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:8.0 volumeClaimTemplates: # ✅PVC模板StatefulSet特有生成一一对应的PVC - metadata: name: data spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 10Gi updateStrategy: # StatefulSet更新策略和Deployment完全不一样 type: RollingUpdate rollingUpdate: partition: 0没有更新策略因为是串行启动多了serviceNamedaemonsetapiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit spec: selector: matchLabels: app: fluent-bit template: metadata: labels: app: fluent-bit spec: # tolerationsDaemonSet几乎必配容忍度否则不能调度到master节点 tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule containers: - name: fluent-bit image: fluent/fluent-bit:latest updateStrategy: # DaemonSet更新策略 type: RollingUpdate rollingUpdate: maxUnavailable: 1
