Pod是Kubernetes中能够创建和部署的最小单元,是Kubernetes集群中的一个应用实例,总是部署在同一个节点Node上。Pod中包含了一个或多个容器,还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境,Docker则是最流行的容器环境。
多容器Pod示意图:
Pod并不提供保证正常运行的能力,因为可能遭受Node节点的物理故障、网络分区等等的影响,整体的高可用是Kubernetes集群通过在集群内调度Node来实现的。通常情况下我们不要直接创建Pod,一般都是通过Controller来进行管理,但是了解Pod对于我们熟悉控制器非常有好处。
pod的管理主要有RC(RS)、Deployment、StatefulSet、DaemonSet和Job(CronJob)等
Replication Controller
Replication Controller简称RC,简单来说,RC可以保证在任意时间运行Pod的副本数量,能够保证Pod总是可用的。总维持pod是指定的副本数量运行。
Replication Set
Replication Set简称RS,随着Kubernetes的发展,RS在RC的基础上做了一些扩展,官方已经推荐使用RS和Deployment来代替RC了。
apiVersion: v1
kind: ReplicationController/Replication Set
metadata:
name: rc-test
labels:
name: rc
spec:
replicas: 3
selector:
name: rc
...................................
Deployment
主要职责和RC一样的都是保证Pod的数量和健康,二者大部分功能都是完全一致的,可以看成是一个升级版的RC控制器。比如一些官方组件kube-dns、kube-proxy也都是使用的Deployment来管理的.
新特性如下:
RS的全部功能:Deployment具备上面描述的RC的全部功能
事件和状态查看:可以查看Deployment的升级详细进度和状态
回滚:当升级Pod的时候如果出现问题,可以使用回滚操作回滚到之前的任一版本
版本记录:每一次对Deployment的操作,都能够保存下来,这也是保证可以回滚到任一版本的基础
暂停和启动:对于每一次升级都能够随时暂停和启动
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: test
labels:
k8s-app: test
spec:
replicas: 3
template:
metadata:
labels:
app: mysql
....................................
DaemonSet
DaemonSet适用于在每个Node都需要运行一个Pod的时候使用,比如:每一个Node上运行一个日志采集、性能监控的Pod,可以通过DaemonSet来实现
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-ds-test
spec:
selector:
matchLabels:
name: node-ds-test
template:
metadata:
labels:
...........................
StatefulSet
StatefulSet是Kubernetes提供的管理有状态应用的负载管理控制器API。在Pods管理的基础上,保证Pods的顺序和一致性。与Deployment一样,StatefulSet也是使用容器的Spec来创建Pod,与之不同StatefulSet创建的Pods在生命周期中会保持持久的标记
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
...........................
Job/CronJob
K8S中,通常用Job来创建一个任务,注意job是执行一个的任务。如需要任务定时周期的去执行。CronJob就出场了,CronJob其实就是在Job的基础上加上了任务调度。
apiVersion: batch/v1
kind: Job/CronJob
metadata:
name: job-test
spec:
template:
metadata:
name: job-test
spec:
restartPolicy: Never
......................
官方推荐我们使用yaml文件的形式来管理pod,我们先用命令的方式来管理pod:
以下就是一些常用的kubectl管理命令
#查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间 -o wide 查看详细信息
kubectl get pod
kubectl get pod -n kube
kubectl get pod -o wide
# 查看 RC 和 service 列表, -o wide 查看详细信息
kubectl get rc,svc
kubectl get pod,svc -o wide
kubectl get pod -o yaml
# 显示 Node 的详细信息
kubectl describe node server2
# 显示 Pod 的详细信息, 特别是查看 pod 无法创建的时候的日志
kubectl describe pod
eg:
kubectl describe pod nginx
# 根据 yaml 创建资源, apply 可以重复执行,create 不行
kubectl create -f pod.yaml
kubectl apply -f pod.yaml
# 基于 pod.yaml 定义的名称删除 pod
kubectl delete -f pod.yaml
# 删除所有包含某个 label 的pod 和 service
kubectl delete pod,svc -l name=
# 删除所有 Pod
kubectl delete pod --all
# 查看 endpoint 列表
kubectl get endpoints
# 执行 pod 的命令
kubectl exec -- date
kubectl exec -- bash
kubectl exec -- ping 172.25.63.1
# 通过bash获得 pod 中某个容器的TTY,相当于登录容器
kubectl exec -it -c -- bash
eg:
kubectl exec -it nginx -- bash
# 查看容器的日志
kubectl logs
kubectl logs -f # 实时查看日志
kubectl log -c # 若 pod 只有一个容器,可以不加 -c
# 查看注释
kubectl explain pod
kubectl explain pod.apiVersion
# 查看节点 labels
kubectl get node --show-labels
运行一个pod:
可以使用kubectl run --help
查看运行的帮助
[root@server1 ~]# kubectl run nginx --image=nginx
pod/nginx created
查看运行的pod:
[root@server1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 3m56s
查看默认namespace的pod:
[root@server1 ~]# kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 4m31s
查看pod的详细信息:
[root@server1 ~]# kubectl describe pod nginx
Name: nginx
Namespace: default
Priority: 0
Node: server2/172.25.63.2 #这个pod运行在哪个节点上
Start Time: Sat, 18 Apr 2020 00:43:38 +0800
Labels: run=nginx #pod的label
Annotations:
Status: Running
IP: 10.244.1.2 #pod的ip地址
IPs:
IP: 10.244.1.2
Containers:
nginx:
......
此时,集群内部的任意节点可以访问pod,但是集群外部无法直接访问:
现在再运行一个容器来访问nginx:
[root@server1 ~]# kubectl run test -it --image=radial/busyboxplus --restart=Never
If you don't see a command prompt, try pressing enter.
/ #
/ # curl 10.244.1.2 #访问第一个pod的ip地址即可。
上述命令中--restart=Never
表示退出之后不重启,默认会重启。
当pod不使用时可以将其删除
删除pod:
[root@server1 ~]# kubectl delete pod nginx
pod "nginx" deleted
[root@server1 ~]# kubectl delete pod test
pod "test" deleted
默认创建pod时使用自主式的pod管理器,这种自主创建的pod再删除时会直接删除,我们也可以指定pod管理器deployment来创建pod,这种管理器在pod删除时会帮我们自动启动:
首先用两种方式创建pod:
[root@server1 ~]# kubectl run nginx --image=nginx
pod/nginx created
[root@server1 ~]# kubectl create deployment myapp --image=ikubernetes/myapp:v1
deployment.apps/myapp created
查看pod信息:
[root@server1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-5d587c4d45-vw5z5 0/1 ContainerCreating 0 13s server3
nginx 1/1 Running 0 5m32s 10.244.1.3 server2
删除自主pod:
[root@server1 ~]# kubectl delete pod nginx
pod "nginx" deleted
[root@server1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-5d587c4d45-vw5z5 1/1 Running 0 116s
可以看到已经被删除,接下来删除指定deployment的pod:
[root@server1 ~]# kubectl delete pod myapp-5d587c4d45-vw5z5
pod "myapp-5d587c4d45-vw5z5" deleted
[root@server1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myapp-5d587c4d45-nplqk 0/1 ContainerCreating 0 26s
可以看到删除pod后deployment又帮我们启动了pod。
基于deployment我们也可以实现拉伸pod的目的:
[root@server1 ~]# kubectl scale --replicas=2 deployment myapp
拉伸成功,同理也可以实现缩减的效果。
此时的pod在集群外部和pod外部并不能被访问,只能在pod内部被访问,要实现集群内部pod外部访问就要借助service,service是一个抽象概念,定义了一个服务的多个pod逻辑合集和访问pod的策略,一般把service成为微服务。
解下来创建service:
[root@server1 ~]# kubectl expose deployment myapp --port=80 --target-port=80
service/myapp exposed
此时pod客户端可以通过service的名称访问后端的两个pod,其中Cluster ip为默认类型,自动分配一个仅集群内部可以访问的虚拟ip。
[root@server1 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
myapp 2/2 2 2 7m24s
[root@server1 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 4h25m
myapp ClusterIP 10.104.223.76 80/TCP 32s
[root@server1 ~]# kubectl describe svc myapp
Name: myapp
Namespace: default
Labels: app=myapp
Annotations:
Selector: app=myapp
Type: ClusterIP
IP: 10.104.223.76
Port: 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.4:80,10.244.2.8:80 #两个pod的地址
Session Affinity: None
Events:
之后测试访问:
[root@server1 ~]# kubectl run test -it --image=radial/busyboxplus
If you don't see a command prompt, try pressing enter.
/ #
/ # curl 10.104.223.76
当然这种方式也只能在集群内部访问,要想实现集群外部访问,我们可以使用NodePort类型暴露端口,让外部客户端访问Pod。
NodePort:在ClusterIp基础上为Service在每台机器上绑定一个端口,这样就可以通过NodeIP:NodePort来访问该服务。
由于集群已经创建,因此要实现集群外部访问需要更改集群网络类型:
[root@server1 ~]# kubectl edit svc myapp
将ClusterIp该为NodePort
当然也可以在创建service时加--type=NodePort
指定类型。
查看暴露出来的端口:
[root@server1 ~]# kubectl get svc myapp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp NodePort 10.104.223.76 80:32516/TCP 6m47s
端口为32516,因此可以使用以下方式访问pod:
[root@foundation63 kiosk]# curl 172.25.63.3:32516
Hello MyApp | Version: v1 | Pod Name
[root@foundation63 kiosk]# curl 172.25.63.2:32516
Hello MyApp | Version: v1 | Pod Name
接下来实现pod的版本更新和回滚:
[root@server1 ~]# kubectl set image deployments myapp myapp=ikubernetes/myapp:v2 --record
deployment.apps/myapp image updated
查看更新历史:
[root@server1 ~]# kubectl rollout history deployment myapp
deployment.apps/myapp
REVISION CHANGE-CAUSE
1
2 kubectl set image deployments myapp myapp=ikubernetes/myapp:v2 --record=true
查看版本:
[root@server1 ~]# curl 172.25.63.3:32516
Hello MyApp | Version: v2 | Pod Name
可以看出已经更新成了v2版本。
回滚到v1:
[root@server1 ~]# kubectl rollout undo deployment myapp --to-revision=1
deployment.apps/myapp rolled back
查看版本:
[root@server1 ~]# curl 172.25.63.3:32516
Hello MyApp | Version: v1 | Pod Name
可以看到版本已经回滚到v1了。