美文网首页
2020-07-31 深入理解Pod对象

2020-07-31 深入理解Pod对象

作者: 阿丧小威 | 来源:发表于2020-08-05 00:10 被阅读0次

    1. Pod基本概念

    • pod是kubernetes最基本的执行单元(最小、最简单的单元),pod表示在集群上运行的进程。
    • pod封装了应用程序容器(某些情况下多个容器),存储资源、唯一网络IP、以及控制器该如何运行的选项。
      • 运行单个容器的pod:一个pod运行一个容器是kubernetes最常见的。
      • 运行多个容器的pod:pod可能封装多个紧密耦合且需要共享资源的共处容器组成的应用程序。
    • 如果希望横向扩展应用程序,则应该使用多个pod,在kubernetes中,称为副本。
    • Pod是短暂的。
    • 每个pod分配一个唯一的IP地址,pod的每个容器共享网络命名空间。包括IP地址和端口。pod内的容器可以使用localhost相互通信。
    • 一个pod可以指定一组共享存储卷。pod中所有的容器都可以访问共享卷,允许这些容器共享数据。卷数据可以持久化。

    2. Pod存在的意义

    • 解决一个docker容器只运行一个程序的限制;pod是多进程模型,可以运行多个应用程序,每个程序由容器来管理。
    • 某些亲密性应用场景是需要多个容器一起运行的;例如:频繁交互数据的两个应用,通过localhost相互访问可以提供性能,防止出现跨节点、跨网络的通信。

    3. Pod实现机制

    在同一个Pod中实现共享网络,使用数据卷volume实现共享存储。

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: write
        image: centos
        command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]
        volumeMounts:
          - name: data
            mountPath: /data
      - name: read
        image: centos
        command: ["bash","-c","tail -f /data/hello"]
        volumeMounts:
          - name: data
            mountPath: /data
    
      volumes:    ---定义数据卷
      - name: data
        emptyDir: {}
    

    4. 镜像拉取策略(imagePullPolicy)

    • IfNotPresent:默认值,镜像在宿主机上不存在时才拉取
    • Always:每次创建Pod 都会重新拉取一次镜像
    • Never:Pod 永远不会主动拉取这个镜像

    默认规则

    apiVersion: v1
    kind: Pod
    metadata:
      name: foo
      namespace: awesomeapps
    spec:
      containers:
        - name: foo
          image: janedoe/awesomeapp:v1
          imagePullPolicy: IfNotPresent
    

    根据凭据拉取镜像

    apiVersion: v1
    kind: Pod
    metadata:
      name: foo
      namespace: awesomeapps
    spec:
      containers:
        - name: foo
          image: janedoe/awesomeapp:v1
      imagePullSecrets:
        - name: registry-pull-secret
    

    示例:使用Always方式拉取一个私有的镜像
    官方链接 https://kubernetes.io/zh/docs/tasks/configure-pod-container/pull-image-private-registry/
    生成secret有2种方式:
    一、使用docker登录的凭证来生成

    • 1.先登录镜像仓库 docker login -u *** -p *** https://registry.cn-shanghai.aliyuncs.com ---仓库根据实际情况更改
    • 2.查看docker登录的凭证 cat .docker/config.json
    • 3.将凭证base64位编码 cat .docker/config.json |base64 -w 0
    • 4.生成token成功,将token保存到yaml模板即可。
    # cat registry-pull-secret.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: registry-pull-secret
    data:
      .dockerconfigjson: eyJjY3IuY2NzLnRlbmNlbnR5dW4uY29tL3RlbmNlbnR5dW4iOnsidXNlcm5hbWUiOiIzMzIxMzM3OTk0IiwicGFzc3dvcmQiOiIxMjM0NTYuY29tIiwiZW1haWwiOiIzMzIxMzM3OTk0QHFxLmNvbSIsImF1dGgiOiJNek15TVRNek56azVORG94TWpNME5UWXVZMjl0In19
    type: kubernetes.io/dockerconfigjson
    # kubectl create -f registry-pull-secret.yaml    ---创建
    # kubectl get secret    ---查看是否创建成功
    

    二、使用kubectl来生成(在集群中创建保存授权令牌的secret)

    • 1.创建 kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
      1. 查看 kubectl get secret regcred --output=yaml

    5. 资源限制

    Pod和Container的资源请求和限制:

    • spec.containers[].resources.limits.cpu

    • spec.containers[].resources.limits.memory

    • spec.containers[].resources.requests.cpu

    • spec.containers[].resources.requests.memory

    • cpu的含义:
      0.1cpu=100m;0.1的cpu在双核,多核机器中的意义是一样的。

    • 内存的含义:
      内存的限制和请求以字节为单位。常见单位 Ei,Pi,Ti,Gi,Mi,Ki。

    • 具有资源请求的pod如何调度:
      当你创建一个pod时,kubernetes调度程序将为pod选择一个节点。每个节点具有每种资源类型的最大容量,调度程序确保对每种资源类型,调度的容器的资源请求综合人小于节点的容量。

    • 具有资源限制的pod如何运行:
      当kubectl启动一个容器时,它会将cpu和内存限制传递到容器运行时 。
      spec.containers[].resource.request.cpu 作用于docker run 命令中的--cpu-shares
      spec.containers[].resource.limits.cpu 作用于docker run 命令中的--cpu-quota
      spec.containers[].resource.limits.memory 作用于 docker run 命令中的--memory

    apiVersion: v1
    kind: Pod
    metadata:
      name: frontend
    spec:
      containers:
      - name: db
        image: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "password"
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"    ---也可以写成0.25
          limits:
            memory: "128Mi"
            cpu: "500m"    ---也可以写成0.5
      - name: wp
        image: wordpress
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
    

    6. Pod重启策略(restartPolicy)

    • Always:当容器终止退出后,总是重启容器,默认策略。
    • OnFailure:当容器异常退出(退出状态码非0)时,才重启容器。
    • Never:当容器终止退出,从不重启容器。
    apiVersion: v1
    kind: Pod
    metadata:
    name: foo
    namespace: awesomeapps
    spec:
    containers:
    -name: foo
    image: janedoe/awesomeapp:v1
    restartPolicy: Always
    

    7. Pod健康检查(Probe)

    Probe有以下两种类型:

    • livenessProbe(存活检查)
      如果检查失败,将杀死容器,根据Pod的restartPolicy来操作。
    • readinessProbe(就绪检查)
      如果检查失败,Kubernetes会把Pod从service endpoints中剔除。

    Probe支持以下三种检查方法:

    • httpGet
      发送HTTP请求,返回200-400范围状态码为成功。
    • exec
      执行Shell命令返回状态码是0为成功。
    • tcpSocket
      发起TCP Socket建立成功。

    探测器配置:

    • initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认0秒;
    • periodSeconds:执行探测器的时间间隔,默认是10秒;
    • timeoutSeconds:探测的超时后等待多少秒。默认值是1,最小值是1;
    • sucsessThreshold:探测器失败后,被视为成功的最小连续成功数。默认值1.存活探测器必须是1.最小值是1;
    • failureThreshold:当pod启动了并探测到失败,kubernetes重试次数,默认值3,最小值1;

    http探测器可以在httpGet上配置额外的字段:

    • host:链接使用的主机名,默认是pod的IP
    • scheme:链接方式,http\https
    • path:访问http的路径
    • httpHeaders:请求证自定义的http头
    • port:访问容器的端口号和端口名,必须在1-65535之间
    vi pod-check.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        test: liveness
      name: liveness-exec
    spec:
      containers:
      - name: liveness
        image: busybox
        args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
        livenessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 5    ---容器初始化之后多长时间做第一次健康检查
          periodSeconds: 5    ---之后多长时间做一个周期性的健康检查
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 5
          periodSeconds: 5
    kubectl create -f pod-check.yaml
    

    一般两种方法都一起配。

    8. Pod调度约束

    图片.png
    • nodeName用于将Pod调度到指定的Node名称上
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-example
      labels:
        app: nginx
    spec:
      nodeName: 192.168.31.65
      containers:
      - name: nginx
        image: nginx:1.15
    
    • nodeSelector用于将Pod调度到匹配Label的Node上
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-example
    spec:
      nodeSelector:
        env_role: dev
      containers:
      - name: nginx
        image: nginx:1.15
    

    使用nodeSelector需要先设置label标签:

    kubectl label nodes 192.168.9.65 env_role=dev
    kubectl label nodes 192.168.9.66 env_role=sit
    kubectl get nodes --show-labels
    

    9. 故障排查

    Pod状态

    常用查看异常命令:

    • kubectl logs type/name #查看容器日志
    • kuberctl describe type/name #查看容器详细描述
    • kubectl exec -it name bash #进入容器内部查看

    相关文章

      网友评论

          本文标题:2020-07-31 深入理解Pod对象

          本文链接:https://www.haomeiwen.com/subject/picxrktx.html