kubernetes之pod超详细解读--第二篇（三）

8.资源对象对pod的调度

??在kubernetes集群中，pod基本上都是容器的载体，通常需要通过相应的资源对象来完成一组pod的调度和自动控制功能，比如：deployment、daemonSet、RC、Job等等。接下来小编将一一介绍这些资源对象如何调度pod。

（1）Deployment/RC 自动化调度

??Deployment/RC的主要功能之一就是自动部署一个容器应用的多个副本，以及持续监控副本数量，在集群内始终维持用户指定的副本数量。
举例：（这里以deployment为例）

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
[[email protected] yaml_file]# kubectl create -f nginx-deployment.yaml #创建deployment
[[email protected] yaml_file]# kubectl get pod  #查看创建的pod

[[email protected] yaml_file]# kubectl get deploy  #查看deploy  状态

[[email protected] yaml_file]# kubectl get rs  #查看RS状态


注意：如果想删除pod，不能直接kubectl delete pod,因为这些pod归deployment管理，如果想删除pod，只需要将replicas设置为0，并删除该deployment即可。
从调度上来说，如果在集群模式下，刚刚创建的3个pod完全是由系统全自动的完成调度，他们最终在哪些节点运行，完全是由master的scheduler经过一系列的复杂算法计算得出的，用户无法干预。

（2）NodeSelector定向调度

??Deployment/RC对pod的调度用户是无法干预的，如果我们想将一个pod定向的在某个特定的节点上运行，那该怎么做呢？还记得之前说过的标签吗，如此强大的功能不用就浪费了，这里我们可以使用node的标签，和pod的nodeSelector属性相匹配，来达到上述的目的。
举例：
#为node创建标签：
[[email protected] yaml_file]# kubectl get node #查看集群node
[[email protected] yaml_file]# kubectl label nodes 127.0.0.1 zone=north #给node打标签

#定义pod：redis-master-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-pod
  labels:
    name: node-pod
spec:
  containers:
  - name:  node-pod
    image: docker.io/kubeguide/redis-master
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
  nodeSelector:
    zone: north
[[email protected] yaml_file]# kubectl create -f redis-master-pod.yaml

这样，pod就会被定向到有zone: north 标签的node上去运行，当然这里如果定义的deployment/RC的话，会根据副本数，在相应的具有标签的node上运行。

（3） DaemonSet

??DaemonSet是kubernetes在v1.2版本更新的时候新增的一种资源对象，用于管理在集群汇总每一个node上仅运行一份pod的副本实例。（如下图）

DaemonSet的应用场景有：
?? 在每一个node上运行一个GlusterFS存储或者Ceph存储的Daeson进程
?? 在每个node上运行一个日志采集程序，例如：Fluentd或者Logstach
?? 在每台node上运行一个性能监控程序，采集node的运行性能数据，如：Prometheus、collectd、New Relic agent
?接下来小编就给出一个例子定义为在每台node上启动一个fluentd容器，配置文件fluentd-ds.yaml的内容如下，其挂载了物理机的两个目录“/var/log”和“/var/lib/docker/containers”：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd-cloud-logging
  namespace: kube-system
  labels:
    k8s-app: fluentd-cloud-logging
spec:
  template:
    metadata:
      namespace: kube-system
      labels:
        k8s-app: fluentd-cloud-logging
    spec:
      containers:
      - name: fluentd-cloud-logging
        image: docker.io/forkdelta/fluentd-elasticsearch
        resrouces:
          limits:
            cpu: 100m
            memory: 200Mi
        env:
        - name: FLUENTD_ARGS
          value: -q
        volumeMounts:
        - name: varlog
          mountPath: /var/log
          readOnly: false
        - name: containers
          mountPath: /var/lib/dpcker/containers
          readOnly: false
    volumes:
    - name: containers
      hostPath:
        path: /var/lib/dpcker/containers
    - name: varlog
      hostPath:
        path: /var/log

（4） job：批处理调度

??Kubernetes在v1.2版本开始支持批处理类型的应用，可以通过kubernetes Job资源对象来定义并启动一个批处理任务。批处理任务提高通常并行（或者串行）启动多个计算进程去处理一批工作项（work items），处理完成之后，整个批处理任务结束。
?批处理任务可以分为以下几种模式：
??? Job Template Expansion模式：一个Job对象对应一个待处理的work item，有几个work items就会产生几个独立的job（通常适合work items较少，但是处理的数据量比较大的场景）

??? Queue with Pod Work Item模式：采用一个任务队列存放Work Items，一个job对象作为消费者去完成这些Work Items，这种模式下会启动一个Job和N个Pod，每一个Pod对应一个Work Item

??? Queue with Varibale Pod Conut模式：这也是采用的Work Items的方式，但是不同的是，一个Job启动的pod的数量是可以改变的

??? Single Job with Static Work Assignment模式：也是一个job产生多个pod完成任务，但是它采用的静态方式分配任务，而并非任务队列的方式动态分配
几种批处理任务的模式对比

考虑到批处理的并行问题，kubernetes将job分为以下三种类型：
?? Non-parallel Jobs：通常一个job只启动一个pod，只有pod异常才会重启pod，pod正常结束，Job也结束
?? Parallel Jobs with a fixed completion count：并行Job会启动多个pod，正常的pod结束的数量达到设定的值后，Job结束。其中有两个参数
???? Spec.completions：预期的pod正常退出的个数
????Spec.parallelism：启动的Job数
?? Parallel Jobs with a work queue：所有的work item都在一个queue中，Job启动的pod能判断是否queue中还有任务需要处理，如果某个pod正常结束，job不会启动新的pod，如果有一个pod结束，那么job下其他pod将不存在干活的情况，至少有一个pod正常结束时，job算成功结束。


接下来小编介绍一下上面三种常见的批处理模型在kubernetes中的实例：

Job Template Expansion模式：

apiVersion: batch/v1
kind: Job
medata:
  name: process-item-$ITEM
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: docker.io/busybox
        imagePullPolicy: IfNotPresent
        command: ["sh","-c","echo Processing item $ITEM && sleep 5"]
      restartPolicy: Never
#以上面的yaml内容为模板，创建三个job的定义文件：
[[email protected] yaml_file]# for i in apple banana cherry ;do cat job.yaml |sed "s/\$ITEM/$i/" > job-$i.yaml ;done
[[email protected] yaml_file]#mkdir jobs && mv job-* jobs  #将job的定义文件统一放入jobs目录下
[[email protected] yaml_file]# kubectl create -f jobs  #创建job
[[email protected] yaml_file]# kubectl get jobs 查看job

[[email protected] yaml_file]# docker ps -a  #通过查看创建container，查看任务打印的内容
[[email protected] yaml_file]# kubectl get pod --show-all  #查看pod

Queue with Pod Work Item模式：
??在这种模式下需要一个任务队列存放work items，比如kafka、RabbitMQ,客户端将需要处理的任务放入队列中，然后编写worker程序并打包成为镜像并定义成为Job中的work Pod，worker程序的实现逻辑就是从任务队列中拉取一个work item并处理，处理完结束进程。

Queue with Varibale Pod Conut模式：
??这种模式下worker程序需要知道队列中是否还有等待处理的work item，如果有就取出来并处理，否则认为所有的工作完成，job结束。此处的任务队列通常用Redis来实现。

（5） Cronjob 定时任务

??Kubernetes从v1.5版本开始增加了一个新类型的Job，类似于Linux crond的定时任务，Crond Job,下面，小编向大家介绍一下这个类型的Job如何使用。
??先想使用这个类型的Job，必须是kubernetes1.5版本以上，并且在启动API server是加入参数：--runtime-config=batch/v2alpha1=true（在apiserver 的配置文件中加入/etc/kubernetes/apiserver）

然后重启：[[email protected] yaml_file]# systemctl restart kube-apiserver
#编写crond Job的定义：
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: docker.io/busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hell from the Kubernetes cluster
          restartPolicy: OnFailure
[[email protected] yaml_file]# kubectl create -f cron.yaml #创建CronJob
[[email protected] yaml_file]# kubectl get cronjob  #查看CronJob任务

[[email protected] yaml_file]# kubectl get jobs --watch  #查看job，可以发现有每分钟都会有一个job执行

注意：这里的任务执行的周期与linux crond相同（分 时 日 月 周）

9.Init Container 初始化容器

??在很多场景下，我们在启动应用之前需要进行一些列的初始化，在kubernetes1.5版本之后，init Container被应用于启动应用容器之前启动一个或者多个“初始化”容器，完成应用容器所需要的预置条件。它们仅仅运行一次就结束，当所有定义的init Container都正常启动之后，才会启动应用容器。
下面小编演示一个案例：在启动nginx服务之前，通过初始化buxybox为nginx创建一个index.html主页：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  initContainers:
  - name: install
    image: docker.io/busybox
    imagePullPolicy: IfNotPresent
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  containers:
  - name: ngxin
    image: docker.io/nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

这里注意如果是k8s的版本比较低的话，这里的initContainers 不会被识别，可能会报错：

使用init container的注意事项：
??? 如果定义多个init container，必须上一个运行完成才能运行下一个
??? 多个init container定义资源请求，取最大的那个为有效请求
??? Pod重启时，init container会跟着重启

10.pod的升级和回滚

(1)pod的升级

??当我们新应用部署的时候，需要将pod中image换成新打包的image，但是由于在生产环境，又不能让服务较长时间的不可用，这时kubernetes提供了滚动升级功能来解决这个难题。
小编这里以deployment为例，用三个nginx的服务，进行image的替换，查看究竟kubernetes如何实现滚动升级的：

#nginx-deplyment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
[[email protected] yaml_file]# kubectl  create -f nginx-deployment.yaml
[[email protected] yaml_file]# kubectl get pod  #查看pod

[[email protected] yaml_file]# kubectl get rs  #查看由deployment创建的RS


#此时我们将pod中的image设置为docker.io/linuxserver/nginx
[[email protected] yaml_file]# kubectl set image deployment/nginx-deployment nginx=docker.io/linuxserver/nginx
或者：

[[email protected] yaml_file]# kubectl edit deployment/nginx-deployment
[[email protected] yaml_file]# kubectl rollout status deployment/nginx-deployment #可以查看滚动升级的过程
#我们查看具体的更新细节
[[email protected] yaml_file]# kubectl describe deployment/nginx-deployment

[[email protected] yaml_file]# kubectl get rs  #查看RS


那到底是怎么更新的呢？由上面的截图我们可以看出：
初始创建deployment时，系统创建了一个RS并按照配置的replicas创建了3个Pod，当deployment更新时，系统又创建了一个新的RS，逐渐的将旧的RS的副本数从3缩小到0，而将新的RS的副本数从0逐渐增加到3，最后就是以这样的方式，在服务不停止的情况下巧妙的完成了更新。
更新策略：
?? Recereate（重构）：设置：spec.strategy.type=Recreate,表示deployment更新过程中会先杀死所有正在运行的pod，然后在重新创建。（会造成服务中断）
?? RollingUpdate（滚动更新）：设置：spec.strategy.type=RollingUpdate,表示deployment以滚动更新的方式来逐渐更新pod，滚动更新有两个重要的参数
????spec.strategy.type.rollingUpdate.maxUnavailabe：用于指定deployment在更新过程中不可用pod的数量的上限（v1.6之后默认将1改为25%）：也就是说，当这个值设置为2的时候，并且replicas是5的话，在更新时至少要有3个pod能正常提供对外服务。
????spec.strategy.type.rollingUpdate.maxSurge：表示指定deployment更新Pod过程中Pod总数不能超过Pod期望副本数部分的最大值（v1.6之后默认将1改为25%），也就是说，当这个值设置为2的时候，并且replicas是5的话，正在运行的Pod不能超过7个。
更新的注意点：
?? deployment会为每一次更新都创建一个RS，如果当deployment本次更新未完成，用户又发起了下一次更新，此时deployment不会等本次更新完成之后再进行下一次更新，它会将本次更新的所有的Pod全部杀死，直接进入下一次更新
?? 关于更新label和label selector的问题
???? 更新时deployment的标签选择器时，必须同时更新deployment中定义的pod的label，否则deployment更新会报错
???? 添加或者修改deployment的标签选择器时会导致新的标签选择器不会匹配就选择器创建的RS和Pod，则这些RS和Pod处于孤立状态，不会被系统自动删除
???? 在deployment的selector中删除一个或者多个标签，deployment的RS和Pod不会受到影响，但是被删除的label仍然会留在已有的RS和Pod中

(2)pod的回滚

??有时，因为新版本不稳定时，我们可能将deployment回滚到旧的版本，默认情况下deployment发布的所有历史记录都会留在系统中，这里小编向大家展示如何回退版本：
#查看deployment历史
[[email protected] yaml_file]# kubectl rollout history deployment/nginx-deployment

这里我们看不见deployment创建的命令，如果在创建deployment加入--record参数，这里就能看见deployment的创建命令
#查看某个特定版本的deployment的详细信息
[[email protected] yaml_file]# kubectl rollout history deployment/nginx-deployment --revision=1

#撤销本次发布并回退上一个部署版本
[[email protected] yaml_file]# kubectl rollout undo deployment/nginx-deployment

#回滚到特定的版本
[[email protected] yaml_file]# kubectl rollout undo deployment/nginx-deployment --to-revision=2

(3)pod的更新和回滚的补充说明

① 暂停或恢复deployment的部署操作
??对于一次复杂的deployment的配置修改，为了避免频繁的更新deployment，我们可以先暂停deployment的更新操作，然后进行配置，再恢复更新，一次性触发完整的更新操作。
#暂停deployment的更新
[[email protected] yaml_file]# kubectl rollout pause deployment/nginx-deployment
之后我们可以做一系列的操作，更新image，设置资源。（这里修改之后不会触发更新）
#恢复更新
[[email protected] yaml_file]# kubectl rollout resume deployment/nginx-deployment
恢复之后，该deployment会一次性更新所有操作。

② 使用kubeclt rolling-update命令完成RC的更新
??对于RC的更新我们可以通过命令kubeclt rolling-update实现。但是该命令会创建一个新的RC，并将旧的RC的pod逐渐降低到0，新的RC的pod逐渐增加到replicas设置的值，并且新的RC必须和旧的RC在同一namespace下。
这里小编以一个例子演示：

#redis-mater-controller-v2.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-v2
  labels:
    name: redis-master-v3
    new-version: v3
spec:
  replicas: 1
  selector:
    name: redis-master-v3
    new-version: v3
  template:
    metadata:
      labels:
        name: redis-master-v3
        new-version: v3
    spec:
      containers:
      - name: master
        image: docker.io/kubeguide/redis-master:v3.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 6379
[[email protected] yaml_file]# kubectl create -f redis-mater-controller-v2.yaml #创建这个RC

此时我们想将image替换成v3.0，这是就需要对RC滚动升级，这里注意两点：
?? RC的名字不能与旧的RC的名字相同
?? 在selector中应至少有一个Label与旧的RC的label不同
#更新
[[email protected] yaml_file]# kubectl rolling-update redis-master-v2 -f redis-mater-controller-v3.yaml

#回滚
[[email protected] yaml_file]# kubectl rolling-update redis-master-v3 --image=docker.io/kubeguide/redis-master --rollback
注意：RC的滚动升级不具有deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制。

③ 其他管理对象的更新策略
?? DaemonSet的更新：OnDelete 和 RollingUpdate两种方式
?? StatefulSet的更新：kubernetes1.6之后，开始逐渐对StatefulSet的更新向deployment看齐，目前了解较少

11.pod的扩容和缩容

??在实际的生产中，我们经常会遇到某个服务因为压力过大，需要扩容，有可能遇到当集群资源过度紧张的时候，减少一部分服务的副本。在kubernetes中我们可以利用deployment的Scale实现。
??Kubernetes对pod的扩容和缩容提供了手动和自动的两种方式。手动则是执行命令，而自动测试更具某个性能指标，并指定pod的副本数量范围，由系统自动的在这个范围内根据性能指标进行调整。
① 手动扩容
#这里以一个简单的nginx为例：


这里deployment管理3个pod的副本，我们将其设置为5个

[[email protected] yaml_file]# kubectl scale deployment nginx-deployment --replicas=5


#在缩容到1个

[[email protected] yaml_file]# kubectl scale deployment nginx-deployment --replicas=1


② 自动扩容
??从kubernetes1.1开始，新增了一个名为Horizontal Pod Autoscaler(HPA)的控制器，用于实现CPU使用率进行自动Pod扩容和缩容。（这里必须先安装Heapster）

??这里小编也是一个案例说明，我们创建一个Tomcat的pod由deployment管理，并且提供一个service供外部访问，同时设置HPA实时监控deploy的CPU使用率，自动pod扩容，最后使用一个循环压力测试这个服务（不断地访问Tomcat），查看deploy的扩容与缩容情况：

#tomcat-apache-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tocamt-apache
spec:
  replicas: 1
  template:
    metadata:
      name: tocamt-apache
      labels:
        app: tocamt-apache
    spec:
      containers:
      - name: tocamt-apache
        image: tomcat
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 20m  #注意这里一定要设置cpu的请求，不然Heapster无法采集
        ports:
        - containerPort: 80
#tomcat-apache-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: tomcat-apache
spec:
  ports:
  - port: 80
  selector:
    app: tocamt-apache

#定义或者创建HPA：

[[email protected] yaml_file]# kubectl autoscale deployment tomcat-apache  --min=1 --max=10 --cpu-percent=50

命令解释：表示pod的数量在1~10之间，以使得平均podCPU使用率维持在50%
或者yaml文件：

#hpa-tomcat-apache.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: tomcat-apache
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: tocamt-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

最后我们在创建一个busybox 的pod，然后进入容器，执行

while true;do wget -q -O- http:ClusterIP >dev/null ;done

对这个deployment进行压力测试，最后可以看到deploy管理的这个pod的数量数变化的，但始终保持pod平均的CPU使用率在50%左右，当将这个压力测试的容器关闭时，pod的数量又会变成原先定义的1个。

问题解答

1. 创建pod时一直处于ContainerCreating的状态，用[[email protected] yaml_file]# kubectl describe pod frontend的时候发现如下报错：


原因：根据报错信息，pod启动需要registry.access.redhat.com/rhel7/pod-infrastructure:latest镜像，需要去红帽仓库里下载，但是没有证书，安装证书之后就可以了。
解决：
① 确认docker是否正常启动

[[email protected] ~]# systemctl status docker


② 下载相应的镜像

[[email protected] ~]# docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

不出意外会报错：

这是因为：
/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory
此时我们下载相应的rpm包：

[[email protected] ~]#wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm
[[email protected] ~]#rpm -ivh python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm

然后执行以下命令：

[[email protected] ~]#rpm2cpio python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm | cpio -iv --to-stdout ./etc/rhsm/ca/redhat-uep.pem | tee /etc/rhsm/ca/redhat-uep.pem

此时/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt文件中就会有内容，再次下载镜像即可。

2. 版本问题

当在创建deployment时，用的apiVersion时：使用的是apps / v1beta1发现报错：

原因：应用程序API组将是v1部署类型所在的位置。 apps / v1beta1版本已在1.6.0中添加，因此如果您有1.5.x客户端或服务器，则仍应使用extensions / v1beta1版本。
查看kubernetes的版本：

[[email protected] yaml_file]# kubelet –version


解决：apiVersion：extensions / v1beta1 即可

3. Kubernetes安装heapster插件

#下载相应的镜像：
[[email protected] yaml_file]# docker pull docker.io/forestgun007/heapster_grafana:v3.1.1
[[email protected] yaml_file]# docker pull docker.io/sailsxu/heapster_influxdb:v0.6
[[email protected] yaml_file]# docker pull docker.io/mxpan/heapster:canary

编写相应的yaml文件：

#grafana-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-grafana
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: grafana
    spec:
      volumes:
      - name: grafana-storage
        emptyDir: {}
      containers:
      - name: grafana
        image: docker.io/forestgun007/heapster_grafana:v3.1.1
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 3000
            protocol: TCP
        volumeMounts:
        - mountPath: /var
          name: grafana-storage
        env:
        - name: INFLUXDB_HOST
          value: monitoring-influxdb
        - name: GRAFANA_PORT
          value: "3000"
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE
          value: Admin
        - name: GF_SERVER_ROOT_URL
          value: /
#grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    kubernetes.io/cluster-service: ‘true‘
    kubernetes.io/name: monitoring-grafana
  name: monitoring-grafana
  namespace: kube-system
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 3000
  selector:
    k8s-app: grafana
#influxdb-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-influxdb
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: influxdb
    spec:
      volumes:
      - name: influxdb-storage
        emptyDir: {}
      containers:
      - name: influxdb
        image: docker.io/sailsxu/heapster_influxdb:v0.6
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /data
          name: influxdb-storage
#influxdb-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    kubernetes.io/cluster-service: ‘true‘
    kubernetes.io/name: monitoring-influxdb
  name: monitoring-influxdb
  namespace: kube-system
spec:
  # type: NodePort
  ports:
  - name: api
    port: 8086
    targetPort: 8086
  selector:
    k8s-app: influxdb
#heapster-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: heapster
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: heapster
        version: v6
    spec:
      containers:
      - name: heapster
        image: docker.io/mxpan/heapster:canary
        imagePullPolicy: IfNotPresent
        command:
        - /heapster
        - --source=kubernetes:https://kubernetes.default
        - --sink=influxdb:influxdb:http://monitoring-influxdb.kube-system.svc:8086
#heapster-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    kubernetes.io/cluster-service: ‘true‘
    kubernetes.io/name: Heapster
  name: heapster
  namespace: kube-system
spec:
  ports:
  - port: 80
    targetPort: 8082
  selector:
    k8s-app: heapster

最后将这六个文件移动到一个目录下，比如：heapster

[[email protected] ~]# kubectl create -f  heapster  #创建

原文地址：https://blog.51cto.com/14048416/2396850

时间： 2024-08-01 08:21:52

kubernetes之pod超详细解读--第二篇（三）的相关文章

kubernetes之pod超详细解读--第一篇（三）

   小编在这里向各位博友道个歉,上篇文章确实写的有些应付,但怎么说,部署确实因人而异,而且很少有刚刚进公司就让你搭建一个集群,一般公司都有自己的集群,所以小编觉得,侧重点不应该在安装,应该在维护!虽然有些牵强,但小编保证,这一篇绝对有质量!希望看了小编的博客,大家对pod有更深入的认识.   这篇文章,小编打算介绍关于pod的11个重要的知识点,大家要有耐心的看下去哦!虽然内容比较多,有兴趣的朋友可以细细阅读,小编会尽可能的用比较容易理解的话和图,去介绍比较重要并且难以理解的地方. 1. po

中华人民共和国建筑工业行业标准—IFC详细解读 第二篇

未完,待续

jquery jtemplates.js模板渲染引擎的详细用法第二篇

jquery jtemplates.js模板渲染引擎的详细用法第二篇 关于jtemplates.js的用法在第一篇中已经讲过了,这里就直接上代码,不同之处是绑定模板的方式,这里讲模板的数据专门写一个template.html的文件来展示 <span style="font-family:Microsoft YaHei;font-size:14px;"><!doctype html> <html lang="zh-CN"> <

[转帖]分层存储超详细解读，为什么大数据时代它已不可或缺

分层存储超详细解读,为什么大数据时代它已不可或缺 http://www.itpub.net/2019/10/16/3467/ 如今,分层存储已成为了一种常见的存储方法,它将数据存储在具有不同特性(如性能.成本和容量)的不同存储介质上.不同的存储媒介被分配到不同的层次结构中,其中最高性能的存储媒介被认为是第0层或第1层,然后是第2层.第3层等等. 0层或1层通常是由闪存或基于3D Xpoint技术的固态硬盘(SSD)组成,以此往下的存储层可能涉及高性能光纤通道或SAS驱动器(或RAID阵列),较低

kubernetes之CI/CD工具jenkins第二篇，helm的使用

1. kubernetes之CI/CD第二篇-jenkins结合helm部署应用: 1. 概述: ?? 在前期的博文中我已经初步介绍过kubernetes环境下的CI/CD的使用.主要是jenkins slave pod自动创建和销毁,当有jenkins job任务执行的时候,就会自动创建一个jenkins slave pod.在本篇博文中,我们将介绍jenkins生成slave pod的另外一种方法,就是在pipeline脚本里面定义slave pod的镜像等,同时将Dockerfile.Je

MemCache超详细解读

MemCache是什么 MemCache是一个自由.源码开放.高性能.分布式的分布式内存对象缓存系统,用于动态Web应用以减轻数据库的负载.它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提高了网站访问的速度.MemCaChe是一个存储键值对的HashMap,在内存中对任意的数据(比如字符串.对象等)所使用的key-value存储,数据可以来自数据库调用.API调用,或者页面渲染的结果.MemCache设计理念就是小而强大,它简单的设计促进了快速部署.易于开发并解决面对大规模的数据缓存的

详细解读Volley（三）—— ImageLoader &amp; NetworkImageView

ImageLoader是一个加载网络图片的封装类,其内部还是由ImageRequest来实现的.但因为源码中没有提供磁盘缓存的设置,所以咱们还需要去源码中进行修改,让我们可以更加自如的设定是否进行磁盘缓存. 一.添加对磁盘缓存的控制 我们默默的打开源码,添加如下代码: private boolean mShouldCache = true; /** * Set whether or not responses to this request should be cached(Disk Cache

关于peersim样例配置文件的超详细解读（新手勿喷）

相信很多兄弟一开始接触peersim,对配置文件还是有点不适应,我看了好久的样例的配置文件,一层层去找对应的文件的方法,终于好像悟懂了一点,记下来以后回顾. 贴上代码,一点点分析. 首先要说下所谓的配置文件,其实就是一个txt文件,语法也是非常简单,类似java里的给类里的变量赋值,这也正对应了配置文件的作用,配置文件,当然就是为实验的参数进行配置用的,所以配置文件的主要功能就是配置各类参数,定义一些协议类.控制类.初始化类以及一些常数. 1 # PEERSIM EXAMPLE 1 #配置文件中

API解读第二篇——执行SQL的核心对象（JDBC）

结构图 核心对象 Statement Statement主要用来执行SQL语句.它执行SQL语句的步骤为: 第一步:创建statement对象. 第二步:配置statement对象,此步骤可以忽略. 第三步:调用statement的executeXXX方法执行SQL语句. 第四步:处理结果集.示例中只是打印结果集. 第五步:关闭statement对象. Statement执行SQL语句的方法有四种类型. execute执行返回结果包含一个或者多个结果集,或结果包含一个或多个更新记录数量的SQL语