k8s实战 ---- pod 基础

如果你对k8s还不了解,可以看下前文

k8s 实战 1 ---- 初识       (https://www.cnblogs.com/jilodream/p/18245222)

什么是pod,pod在英文中是豌豆荚、分离仓、集装箱的意思。
在k8s中,pod就是融合一堆容器实例的一个大容器(称之为集合更贴切)。
K8s所能部署的最小单元就是容器,就是pod,一个pod可以包含一个容器,也可以包含多个容器。
k8s以pod为最小单元将调度容器到指定的节点上,而无法直接调度某一个具体的容器。因此如果pod中有多个容器的话,那么他们共享同一个ip地址,共享同一套端口列表。
那么我们该如何创建一个pod呢?目前最推荐的做法就是以yaml文件的形式,声明pod,并提交创建。(防盗连接:本文首发自http://www.cnblogs.com/jilodream/ )
举个例子:

 1 apiVersion: v1
 2 kind: Pod
 3 metadata:
 4   name: kuard-p
 5 spec:
 6   containers:
 7     - image: docker.io/library/kuard-amd64:blue
 8       name: kuard-c
 9       ports:
10         - containerPort: 8080
11           name: http
12           protocol: TCP

apiVersion指的是调用的k8s api的版本,我们目前使用的是v1版本,这个参数不用太关心。
kind表示我们要创造的资源的类型,k8s除了pod,还有service deployment configmap等等非常多的资源,我们这里传入pod。
对于其他类型的资源大家不要着急,后面需要对每一种常用资源都掌握,才能算熟练掌握k8s的使用。
metadata元数据,通常会定义关于描述资源的一些基本信息。如标签,名称等。至于什么是标签,这点和java中的注解非常类似,非常重要,但是并不是一定要用,这里我们先跳过。
只定义资源的名称。
specspec是specification的缩写,表示规格,也就是你想定义的资源究竟是什么样子的 ?
本文中,(防盗连接:本文首发自http://www.cnblogs.com/jilodream/ )我们定义的spec是需要一系列的容器(虽然只有一个)containers。
containers表示我们需要定义一些容器,其中的每一个 '- image' 表示我们每一个容器的定义,熟悉yaml定义的同学肯定知道,这是数组的含义。
containers,每一个元素分别需要标明:
image 容器所需镜像
name容器的名称
ports容器的端口列表

ports 中每一个端口又需要依次定义:
containerPort 容器的端口号,
name 端口名称
protocol端口使用的协议

这样一份最简单的pod资源定义就算完成了。前文中有讲过,我们需要使用kubectl客户端来和k8s (api server)交互:
首先将上边的模板保存到一份yaml中,假若我们定义为 learnPod.yaml

(1)要求k8s 按照yaml文件创建资源:

kubectl  create -f xxx.yaml   # xxx.yaml为文件名称

1 [root@iZ2ze3bpa0o5cw6gp42ry2Z learnK8s]# k create -f learnPod.yaml 
2 pod/busyb-p created

(2)查询k8s中的pod资源用如下命令:
kubectl get pods

[root@iZ2ze3bpa0o5cw6gp42ry2Z learnK8s]# k get pods
NAME                              READY   STATUS    RESTARTS   AGE
busyb-p                           1/1     Running   0          23m

(3) 删除k8s中的资源使用如下命令:

kubectl delete pods xxx (xxx为资源名称)

1 [root@iZ2ze3bpa0o5cw6gp42ry2Z learnK8s]# k delete pods busyb-p
2 pod "busyb-p" deleted

(4)重新刷新资源模板

如果我们创建完pod资源,发现有些地方需要修改怎么办:

推荐做法是编辑刚才我们使用 yaml文件,然后重新提交

kubectl  apply -f xxx.yaml

k8s就会按照文件对已有资源进行修改,一般我们会升级镜像,开放新端口这样来用。
如果有时有些特性的修改,无法直接编辑,则只能删除资源,重新创建来生效。

(5)查看资源详情

有时我们还需要查看pod的详情,则可以使用

kubectl describe pods xxx (xxx为资源名称)

我们常常使用此命令来查看pod的具体信息,如镜像的详情,启动状态的变化等

(6)在线编辑资源模板

如果有时我们在线上,临时需要处理一些问题来编辑资源也可以使用
kubectl edit pods xxx

edit 之后直接保存,视为更新pod,不保存,视为不更新pod。

(7)查看pod(准确的说是pod中容器)的日志
kubectl logs -f xxx (xxx为资源名称)

1 [root@iZ2ze3bpa0o5cw6gp42ry2Z learnK8s]# k logs -f busyb-p
2 2024/07/04 08:33:45 Starting kuard version: v0.10.0-blue
3 2024/07/04 08:33:45 **********************************************************************
4 2024/07/04 08:33:45 * WARNING: This server may expose sensitive
5 2024/07/04 08:33:45 * and secret information. Be careful.
6 2024/07/04 08:33:45 **********************************************************************
7 2024/07/04 08:33:45 Config: 
8 {
9   "address": ":8080",

 (8) 有时我们需要进入到容器中,看下容器内的具体信息

kubectl exec -it xxx -- /bin/sh (xxx为资源名称)

进入到pod中去,

[root@iZ2ze3bpa0o5cw6gp42ry2Z learnK8s]# k exec -it busyb-p -- /bin/sh
~ $ ls -l
total 17076
drwxr-xr-x    2 root     root          4096 Mar  4  2019 bin
drwxr-xr-x    5 root     root           360 Jul  4 08:33 dev
drwxr-xr-x    1 root     root          4096 Jul  4 08:33 etc

....

除了pod的基本配置外,我们有时还会根据实际业务来配置pod中镜像的拉去策略到模板中
imagePullPolicy
Always:总是从远程仓库中拉取镜像
ifNotPresent:如果本地仓库中有镜像的话,那么就不拉取,如果本地仓库没有才会选择拉取,这也是默认的拉取策略。
Never:不会从远端拉取镜像,(防盗连接:本文首发自http://www.cnblogs.com/jilodream/ )如果本地有镜像的话就使用,如果没有镜像,则会报错。
imagePullPolicy 属于容器属性,和镜像名称、镜像tag属于同一层级。
如下:

.省略..
spec:
  containers:
    - image: docker.io/library/kuard-amd64:blue
      name: kuard-c
      imagePullPolicy: IfNotPresent
.省略..

除去这些基本的操作,pod的使用,还非常的复杂,如挂载卷、标签的使用,配合更高级的资源使用(如 deployment、service),限于篇幅有限,只能在后边的文章中介绍。

热门相关:BJ妹妹的贵宾粉丝室:我妹妹被邀请到朋友室   绝色符师:龙皇的狂傲妃   天王的专属恋人:独家宝贝   绝宠小医妃:王爷,来一针   我的快递员老公   美食萌后:皇上,喂不饱!