Kubernetes基础-2

原创

tom_tuwei 2019-10-26 11:06:01 博主文章分类：容器云平台 ©著作权

文章标签 service、pod 文章分类 运维

©著作权归作者所有：来自51CTO博客作者tom_tuwei的原创作品，请联系作者获取转载授权，否则将追究法律责任

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名称访问