《云原生-Kubernetes篇》深入剖析Kubernetes中pod的原理

简介: 《云原生-Kubernetes篇》深入剖析Kubernetes中pod的原理

正文


本文是《云原生-k8s-深入剖析k8s》学习笔记的第二篇,主要解析pod的意义及其使用方法。

pod,是k8s中最小的API对象,是原子调度单位。是超亲密关系容器之间组织和部署的单位。类比地说,pod就是虚拟机,其中的容器就是这个虚拟机里面运行的用户进程。


pod中的所有容器共享network、volume、IP地址,在pod启动的时候,需要先启动一个Infra中间容器,而其它容器都是通过join的方式加入到Infra容器的资源中的。Infra容器是一个用汇编语言编写的,永远处于暂停状态的容器,其唯一的作用就是hold住资源,和pod同生命周期。


initcontainers是一种容器类型,相较于containers类型,前者总是先于后者启动,initcontainers如果有多个,则会按照定义的顺序先后启动,只有当所有的initcontainers都启动成功且退出了,containers用户容器才会启动。


sidecar,是一种容器设计模式,指的是我们可以在一个pod中,启动一个辅助容器来完成一些独立于主容器之外的工作。比如initcontainers容器、Infra容器,都属于sidecar。


在进行上云工作的时候,我们可以把虚拟机类同为一个pod,把里面的进程类同为容器镜像,把有顺序关系的容器,定义为initcontainers。如此才是合理的、松耦合的容器编排诀窍,也是传统应用架构演变到微服务架构最自然的过渡方式。


pod有如下几个重要的属性需要掌握。


nodeSelector,是一个供用户将pod和node进行绑定的字段。


apiVersion: v1
kind: Pod
...
spec:
 # 该pod只能被调度到含有"disktye: ssd"标签的节点上,否则就调度失败
 nodeSelector:
  disktye: ssd

hostAliases,定义了pod中的hosts文件。

apiVersion: v1
kind: Pod
...
spec:
 # /etc/hosts文件的内容将增加如下内容:
 # 10.1.2.3 foo.remote
 # bar.remote foo.remote
 # 这是k8s中唯一设置pod中hosts文件内容的方式
 hostAliases:
 - ip: "10.1.2.3"
  hostnames:
  - "foo.remote"
  - "bar.remote"

shareProcessNamespace,表示pod中的各个容器共享pid namespace。

apiVersion: v1
kind: Pod
...
spec:
 # pod中的nginx容器和shell容器共享进程空间,可以相互看到pod中所有的进程信息
 shareProcessNamespace: true
 containers:
 - name: nginx
   image: nginx
 - name: shell
   image: busybox
   stdin: true
   tty: true

hostNetwork、hostIPC、hostPID,表示pod中的各个容器共享宿主机的网络、IPC和进程空间资源。

apiVersion: v1
kind: Pod
...
spec:
 # pod中的nginx容器和shell容器共享宿主机的网络
 hostNetwork: true
 # pod中的nginx容器和shell容器可以直接和宿主机进行IPC通信
 hostIPC: true
 # pod中的nginx容器和shell容器共享宿主机的进程空间,可以看到宿主机里面运行的所有进程信息
 hostPID: true
 containers:
 - name: nginx
   image: nginx
 - name: shell
   image: busybox
   stdin: true
   tty: true

volumes,表示容器需要挂载的数据卷。常用的类型有:


emptyDir,临时空目录,会在宿主机中特定位置建立匿名目录供pod中的多个容器挂载,从而实现数据共享;

hostPath,指定宿主机中的具名挂载路径;

containers、initContainers,表示容器的类型。其中initContainers是初始化容器,总是先于用户容器containers运行,并且会按照定义的顺序同步执行。

apiVersion: v1
kind: Pod
...
spec:
 # 初始化容器,仅执行cp命令,执行完成就结束,目的是将war拷贝到tomcat的默认目录下
 initContainers:  
 - image: liuy/sample:v2    
   name: war    
   command: ["cp", "/sample.war", "/app"]    
   # 挂载到当前容器的/app目录
   volumeMounts:    
   - mountPath: /app      
     name: app-volume
 # 用户容器,等待初始化容器执行完毕后才启动,运行默认目录下的war对外提供服务
 containers:  
 - image: liuy/tomcat:7.0    
   name: tomcat    
   command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
   # 挂载到当前容器的/root/apache-tomcat-7.0.42-v2/webapps目录
   volumeMounts:    
   - mountPath: /root/apache-tomcat-7.0.42-v2/webapps      
     name: app-volume
   ports:    
   - containerPort: 8080      
     hostPort: 8001 
  # 该pod挂载的数据卷,类型是宿主机中的匿名存储路径
  volumes:  
  - name: app-volume    
    emptyDir: {}

在containers属性下面,又有如下几个需要重点关注的属性:


image,使用的镜像;

command,启动命令;

workingDir,工作目录;

ports,暴露的容器端口及绑定的宿主机端口;

volumeMounts,挂载数据卷的信息;

imagePullPolicy,镜像拉取策略,通常由always、ifNotPresent、never三个级别;

lifeCycle,生命周期钩子,在容器状态发生改变的时候可以设置触发一些钩子事件;

postStart,容器启动后立即执行指定操作,虽然在ENTRYPOINT之后执行,但不能保证ENTRYPOINT已经执行完毕;

preStop,容器被终结之前执行指定操作,容器的终结会因为这个命令被打断,只有当其执行完毕,容器终结才会继续执行;

pod有如下几个状态需要掌握:

  • pending,pod创建请求已经提交,但是pod中的某些容器因为某种原因不能被顺利创建;
  • running,pod已经成功调度到某个节点,并且其中的容器都已经创建成功,且至少有一个正在运行中;
  • succeeded,pod里面的所有容器都正常运行完毕,并且已经退出了,在运行一次性任务时比较常见;
  • failed,pod里面至少有一个容器以非正常的状态退出;
  • unknown,pod的状态不能被持续地汇报给kube-apiserver,可能是主从节点通信出现了问题;

有几种特殊的volume,它们并不是为了存放容器中的数据,也不是为了进行容器之间或者和宿主机之间进行数据共享,而是为了给容器提供预先定义好的数据。这种数据卷被称为”投射数据卷“,projected volume。


  • secret,存放需要加密的数据;
  • configmap,存放不需要加密的,但是应用需要的配置信息;
  • downward api,让pod里面的容器直接获取到这个api对象的信息;
  • service account,让pod里面可以调用k8s的API来控制集群;

pod可以为其中的容器配置探针(probe),用以监控容器的健康检查,而不是以容器镜像是否运行来作为健康检查的依据,因为会存在很多情况,容器是正常运行的,但是无法对外提供服务了,因此探针的健康检查方式更加准确。k8s一旦检测到容器探针发生异常,就会根据设置好的pod恢复机制进行操作,恢复机制restartPolicy有如下几种:


  • always,任何时候容器不在运行状态,就进行重新创建;
  • onFailure,只在容器异常时才进行重新创建;
  • never,从来不重启容器;

默认情况下pod的恢复机制是always,但并不是所有场景下都是合适的,比如initContainers初始化容器执行任务之后就结束了,就不应该设置为always。


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
3天前
|
Kubernetes 应用服务中间件 nginx
【赵渝强老师】K8s中Pod探针的TCPSocketAction
在K8s集群中,kubelet通过探针(如livenessProbe、readinessProbe和startupProbe)检查容器健康状态。探针支持HTTPGetAction、ExecAction和TCPSocketAction三种检查方法。本文重点介绍TCPSocketAction,它通过尝试建立TCP连接来检测容器的健康状况。示例中创建了一个Nginx Pod,并配置了两个探针(readinessProbe和livenessProbe),它们每隔5秒检查一次容器的8080端口,首次检查在启动后10秒进行。若连接失败,容器将重启。视频讲解和命令演示进一步详细说明了这一过程。
121 80
|
14天前
|
Kubernetes 容器 Perl
【赵渝强老师】Kubernetes中Pod的探针
在K8s集群中,kubelet通过三种探针(存活、就绪、启动)检查Pod容器的健康状态。存活探针确保容器运行,失败则重启;就绪探针确保容器准备好服务,失败则从Service中剔除;启动探针确保应用已启动,失败则重启容器。视频讲解和图片详细介绍了这三种探针及其检查方法(HTTPGet、Exec、TCPSocket)。
【赵渝强老师】Kubernetes中Pod的探针
|
6天前
|
Kubernetes 网络协议 Shell
【赵渝强老师】K8s中Pod探针的ExecAction
在K8s集群中,kubelet通过三种探针(存活、就绪、启动)检查容器健康状态,支持HTTPGet、Exec和TCP检查方式。本文重点介绍ExecAction探针,通过在容器内执行Shell命令返回码判断健康状态,并附带视频讲解和实例演示,展示如何配置和使用ExecAction探针进行健康检查。
36 10
|
11天前
|
Kubernetes 应用服务中间件 nginx
【赵渝强老师】K8s中Pod探针的HTTPGetAction
在K8s集群中,kubelet通过探针(如livenessProbe、readinessProbe和startupProbe)检查容器健康状态。HTTPGetAction通过HTTP请求检查容器健康,返回状态码在200-400区间视为成功。示例中创建了基于Nginx镜像的Pod,并配置存活探针,每5秒检测一次。通过命令操作验证探针功能,展示了Pod的健康检查机制。 视频讲解:[Bilibili](https://www.bilibili.com/video/BV1DTtueTEMM)
39 15
|
2月前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
155 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
3月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
3月前
|
Kubernetes Cloud Native 云计算
云原生入门:Kubernetes 和容器化基础
在这篇文章中,我们将一起揭开云原生技术的神秘面纱。通过简单易懂的语言,我们将探索如何利用Kubernetes和容器化技术简化应用的部署和管理。无论你是初学者还是有一定经验的开发者,本文都将为你提供一条清晰的道路,帮助你理解和运用这些强大的工具。让我们从基础开始,逐步深入了解,最终能够自信地使用这些技术来优化我们的工作流程。
|
2月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
2月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
73 3