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地址，并在每个节点上启用一个端口来暴露服务，可以在集群外部访问。       访问地址： : 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记录格式： ..svc.cluster.local   示例： my-svc.my-namespace.svc.cluster.local

小结：

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