Docker 与 K8S学习笔记(十八)—— Pod的使用

简介: Pod 是一组紧密关联的容器集合,它们共享IPC、Network和UTS namespace,是 Kubernetes 调度的基本单元。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。 一、Pod的定义 这里还是以我们

Docker 与 K8S学习笔记(十八)—— Pod的使用


Pod 是一组紧密关联的容器集合,它们共享IPC、Network和UTS namespace,是 Kubernetes 调度的基本单元。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。


一、Pod的定义


这里还是以我们之前做的webapp为例定义一个Pod,这是一个最简单的Pod定义


apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
  - name: webapp
    image: 172.16.194.135:5000/webapp:latest
    ports:
    - containerPort: 5000


关于Pod的定义比较重要的就是kind、spec.containers,kind就是定义资源类型、在spec.containers中主要定义容器所使用的镜像,这里可以定义多个容器。

 

二、Pod的基本使用


在使用Pod前我们需要注意,在Kubernetes中对于长时间运行的容器的要求是:其主程序需要一直在前台运行。如果主程序运行在后台,则Kubernetes会认为Pod执行结束,将会销毁Pod。以webapp镜像为例,它的Dockerfile如下:


FROM java:8
WORKDIR /opt/soft/
EXPOSE 4567
COPY webapp-1.0-SNAPSHOT.jar /opt/soft/webapp.jar
ENTRYPOINT ["java", "-jar", "/opt/soft/webapp.jar"]


接下来,我们尝试一下Pod中多容器的场景,我们的Pod包含两个容器:webapp和busybox,Pod定义如下:


apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
  - name: webapp
    image: 172.16.194.135:5000/webapp:1.0
    ports:
    - containerPort: 5000
  - name: busybox
    image: busybox
    command: ["sh", "-c", "top"]


注意:busybox容器中我们定义了启动命令top,这样做就是为了确保busybox容器始终在前台运行top命令,避免容器直接被销毁。


我们创建Pod,并通过describe可以清楚看到这两个容器的创建过程:


$ sudo kubectl create -f webapp_pod.yaml
pod/webapp created
$ sudo kubectl describe pod webapp
Name:         webapp
Namespace:    default
Priority:     0
Node:         ayato/172.16.194.135
Start Time:   Sat, 08 Jan 2022 05:49:38 +0000
Labels:       app=webapp
Annotations:  <none>
Status:       Running
IP:           172.17.0.6
IPs:
  IP:  172.17.0.6
Containers:
  webapp:
    Container ID:   docker://9c68ef7019126b65e2feba5d4d69e55997a9e573ce585b0bbb6a7cfe2fe20b31
    Image:          172.16.194.135:5000/webapp:1.0
    Image ID:       docker-pullable://172.16.194.135:5000/webapp@sha256:df3a447a013ada0642dec67bb31976f42f1a0699a68873d0452f514fa24e5c77
    Port:           5000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sat, 08 Jan 2022 05:49:40 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-pcr2h (ro)
  busybox:
    Container ID:  docker://0dfd00b5fa8e419bfe0b4a43595c83cb1d4986980914865ae3371e1724c7f568
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:5acba83a746c7608ed544dc1533b87c737a0b0fb730301639a0179f9344b1678
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      top
    State:          Running
      Started:      Sat, 08 Jan 2022 05:49:45 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-pcr2h (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-pcr2h:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-pcr2h
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  3m50s  default-scheduler  Successfully assigned default/webapp to ayato
  Normal  Pulled     3m49s  kubelet            Container image "172.16.194.135:5000/webapp:1.0" already present on machine
  Normal  Created    3m48s  kubelet            Created container webapp
  Normal  Started    3m48s  kubelet            Started container webapp
  Normal  Pulling    3m48s  kubelet            Pulling image "busybox"
  Normal  Pulled     3m44s  kubelet            Successfully pulled image "busybox" in 4.516692787s
  Normal  Created    3m44s  kubelet            Created container busybox
  Normal  Started    3m43s  kubelet            Started container busybox


我们之前说过同一个Pod中的容器共享网络,也就是说我们在busybox容器中可以通过localhost访问webapp的接口,我们尝试一下:


$ sudo kubectl exec -it webapp -c busybox /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # wget http://localhost:4567/api/hello
Connecting to localhost:4567 (127.0.0.1:4567)
saving to 'hello'
hello                100% |******************************************************************************************|    15  0:00:00 ETA
'hello' saved
/ # cat hello
Hello my friend/ #


三、Pod容器共享Volume


同一个Pod中的容器能够共享Pod级别的Volume,Volume可以被定义为各种类型,多个容器分别进行挂载操作。我们还是以webapp和busybox为例,webapp向volume中写log,busybox通过tail命令读log,Pod定义如下:


apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
  - name: webapp
    image: 172.16.194.135:5000/webapp:1.0
    ports:
    - containerPort: 5000
    volumeMounts:
    - name: webapp-logs
      mountPath: /tmp
  - name: busybox
    image: busybox
    command: ["sh", "-c", "tail -f /logs/log.out"]
    volumeMounts:
    - name: webapp-logs
      mountPath: /logs
  volumes:
  - name: webapp-logs
    emptyDir: {}


我们通过Pod定义中可以看到:我们设置了一个Volume,名称为webapp-logs,type为emptyDir。容器webapp将Volume挂载到/tmp目录,因为webapp配置了logback并会向/tmp中写日志。容器busybox将Volume挂载到/logs目录,并通过tail命令持续读日志。我们启动Pod,并使用kubectl logs命令从busybox中读取tail的输出:


$ sudo kubectl create -f webapp_pod.yaml
pod/webapp created
$ sudo kubectl logs webapp -c busybox
06:30:27.810 [INFO ] [main] [org.demo.webapp.todolist.TodoListApplication] Starting TodoListApplication v1.0-SNAPSHOT using Java 1.8.0_111 on webapp with PID 1 (/opt/soft/webapp.jar started by root in /opt/soft)
06:30:27.821 [INFO ] [main] [org.demo.webapp.todolist.TodoListApplication] No active profile set, falling back to default profiles: default
06:30:30.060 [INFO ] [main] [org.springframework.boot.web.embedded.tomcat.TomcatWebServer] Tomcat initialized with port(s): 4567 (http)
06:30:30.079 [INFO ] [main] [org.apache.coyote.http11.Http11NioProtocol] Initializing ProtocolHandler ["http-nio-4567"]
06:30:30.088 [INFO ] [main] [org.apache.catalina.core.StandardService] Starting service [Tomcat]
06:30:30.089 [INFO ] [main] [org.apache.catalina.core.StandardEngine] Starting Servlet engine: [Apache Tomcat/9.0.41]
06:30:30.359 [INFO ] [main] [org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/]] Initializing Spring embedded WebApplicationContext
06:30:30.359 [INFO ] [main] [org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext] Root WebApplicationContext: initialization completed in 2407 ms
06:30:30.913 [INFO ] [main] [org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor] Initializing ExecutorService 'applicationTaskExecutor'
06:30:32.634 [WARN ] [main] [org.springframework.boot.autoconfigure.thymeleaf.ThymeleafAutoConfiguration$DefaultTemplateResolverConfiguration] Cannot find template location: classpath:/templates/ (please add some templates or check your Thymeleaf configuration)
06:30:32.956 [INFO ] [main] [org.apache.coyote.http11.Http11NioProtocol] Starting ProtocolHandler ["http-nio-4567"]
06:30:33.096 [INFO ] [main] [org.springframework.boot.web.embedded.tomcat.TomcatWebServer] Tomcat started on port(s): 4567 (http) with context path ''
06:30:33.131 [INFO ] [main] [org.demo.webapp.todolist.TodoListApplication] Started TodoListApplication in 6.387 seconds (JVM running for 7.205)


关于Volume的类型,有如下几种:


1)emptyDir:emptyDir是在Pod分配到Node时创建的,它的初始内容为空,并且无须指定host上对应的目录文件,它是由Kubernetes自动分配的目录,当Pod销毁后,emptyDir中的数据也会被删除。一般可用作临时空间,存放应用程序临时数据。


2)hostPath:将宿主机中的文件或目录挂载到Pod中。通常用于应用永久数据的存储。


3)iscsi:将iSCSI存储设备上的目录挂载到Pod中。


4)nfs:将NFS上的目录挂载到Pod中。


5)glusterfs:将GlusterFS网络文件系统的目录挂载到Pod中。


6)rbd:将Ceph块设备共享存储挂载到Pod中。


7)gitRepo:通过挂载一个空目录,并从Git中克隆一个git仓库供Pod使用。


8)configmap:将配置数据挂载为容器中的文件。


9)secret:将Secret数据挂载为容器中的文件。


分类: 容器技术

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
15天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
152 77
|
2天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
19 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
1月前
|
关系型数据库 MySQL Java
【Docker最新版教程】一文带你快速入门Docker常见用法,实现容器编排和自动化部署上线项目
Docker快速入门到项目部署,MySQL部署+Nginx部署+docker自定义镜像+docker网络+DockerCompose项目实战一文搞定!
|
26天前
|
运维 Kubernetes Docker
深入理解容器化技术:Docker与Kubernetes的协同工作
深入理解容器化技术:Docker与Kubernetes的协同工作
46 1
|
26天前
|
Kubernetes 开发者 Docker
Docker与Kubernetes的协同工作
Docker与Kubernetes的协同工作
|
23天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
|
2天前
|
Unix Linux Docker
CentOS停更沉寂,RHEL巨变限制源代:Docker容器化技术的兴起助力操作系统新格局
操作系统是计算机系统的核心软件,管理和控制硬件与软件资源,为用户和应用程序提供高效、安全的运行环境。Linux作为开源、跨平台的操作系统,具有高度可定制性、稳定性和安全性,广泛应用于服务器、云计算、物联网等领域。其发展得益于庞大的社区支持,多种发行版如Ubuntu、Debian、Fedora等满足不同需求。
15 4
|
17天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
59 3
|
24天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
58 7
|
24天前
|
存储 Prometheus 监控
Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行
本文深入探讨了在Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行。
30 5