Kubernetes基础-2

1.深入理解Pod对象

 1.Pod容器分类
      • Infrastructure Container： 基础容器
         • 维护整个Pod网络空间
      • InitContainers： 初始化容器
             • 先于业务容器开始执行
      • Containers： 业务容器
          • 并行启动

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

    3.资源限制
       Pod和Container的资源请求和限制：
 • spec.containers[].resources.limits.cpu
 • spec.containers[].resources.limits.memory
 • spec.containers[].resources.requests.cpu
 • spec.containers[].resources.requests.memory
     request可以理解为预分配，即判断集群现有资源，limit和docker资源限制类似。

 4.重启策略（restartPolicy）
    • Always：当容器终止退出后，总是重启容器，默认策略。
  • OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
  • Never：当容器终止退出，从不重启容器。

 5.健康检查（Probe）

    Probe有以下两种类型：
      livenessProbe
   如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。
     readinessProbe
    如果检查失败， Kubernetes会把Pod从service endpoints中剔除。
 Probe支持以下三种检查方法：

httpGet
发送HTTP请求， 返回200-400范围状态码为成功。
exec
执行Shell命令返回状态码是0为成功。
tcpSocket
发起TCP Socket建立成功。
参考网站：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

6.调度约束
• nodeName用于将Pod调度到指定的Node名称上
• nodeSelector用于将Pod调度到匹配Label的Node上

7.故障排查

2.部署应用常用控制器

 1.Pod与controllers的关系

    • controllers：在集群上管理和运行容器的对象
    • 通过label-selector相关联
    • Pod通过控制器实现应用的运维，如伸缩，滚动升级等

    2.Deployment
       • 部署无状态应用
   • 管理Pod和ReplicaSet
         • 具有上线部署、副本设定、滚动升级、回滚等功能
       • 提供声明式更新，例如只更新一个新的Image
         应用场景： Web服务，微服务

    3.DaemonSet
      • 在每一个Node上运行一个Pod
      • 新加入的Node也同样会自动运行一个Pod
            应用场景： Agent
             https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

    4.Job
       Job分为普通任务（Job）和定时任务（CronJob）
   • 一次性执行
    应用场景：离线数据处理，视频解码等业务
            https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

    5.CronJob
       定时任务，像Linux的Crontab一样。
     • 定时任务
             应用场景：通知，备份
        https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

    6.Statefulset
       部署有状态应用，需要考虑网络ID 和存储问题
          如mysql jenkins等

3.Service – 统一入口访问应用

1.service简介
• 防止Pod失联（服务发现）
• 定义一组Pod的访问策略（负载均衡）
• 支持ClusterIP， NodePort以及LoadBalancer三种类型
• Service的底层实现主要有iptables和ipvs二种网络模式

2.Pod与Service的关系
   • 通过label-selector相关联
 • 通过Service实现Pod的负载均衡（TCP/UDP 4层）

3.Service类型
   ClusterIP： 分配一个内部集群IP地址，只能在集群内部访问（同Namespace内的Pod），默认ServiceType。
      ClusterIP 模式的 Service 为你提供的，就是一个 Pod 的稳定的 IP 地址，即 VIP。
 NodePort： 分配一个内部集群IP地址，并在每个节点上启用一个端口来暴露服务，可以在集群外部访问。
       访问地址： <NodeIP>:<NodePort>
 LoadBalancer： 分配一个内部集群IP地址，并在每个节点上启用一个端口来暴露服务。
     除此之外， Kubernetes会请求底层云平台上的负载均衡器，将每个Node（[NodeIP]:[NodePort]）作为后端添加进去。一般云服务提供商支持，自建集群不支持该类型。

4.Service代理模式
        Iptables VS IPVS
   Iptables：

• 灵活，功能强大
• 规则遍历匹配和更新，呈线性时延
• 可扩展性
IPVS：
• 工作在内核态，有更好的性能
• 调度算法丰富： rr， wrr， lc， wlc， ip hash...
默认是iptables模式，如果需要使用ipvs，需要修改configmap（kubeadm方式部署，如果是二进制，修改kube-proxy配置文件），服务器开启ipvs。

 5.DNS
     DNS服务监视Kubernetes API，为每一个Service创建DNS记录用于域名解析。
    ClusterIP A记录格式： <service-name>.<namespace-name>.svc.cluster.local
   示例： my-svc.my-namespace.svc.cluster.local

小结：

1. 采用NodePort对外暴露应用，前面加一个LB实现统一访问入口
   2. 优先使用IPVS代理模式
   3. 集群内应用采用DNS名称访问