文章目录
- 一、Pod管理
- 二、资源清单
- 三、Pod生命周期
- 四、今日报错
一、Pod管理
Pod是可以创建和管理Kubernetes计算的最小可部署单元,一个Pod代表着集群中运行的一个进程,每个pod都有一个唯一的ip。
一个pod类似一个豌豆荚,包含一个或多个容器(通常是docker),多个容器间共享IPC、Network和UTC namespace。
kubectl命令
kubectl run '镜像' --image=‘image name’
kubectl get pod #查看POD内容
kubectl get pod -o wide #详细查看pod内容的
kubectl describe pod 'podname' #仔细查看pod的详细内容
kubectl delete pod 'podname' #删除pod内容
kubectl create
创建
查看
测试效果,访问成功,说明创建没有问题
查看详细的pod内容可以看到IP和容器的信息
kubectl create deployment webserver --image=myapp:v1 #deployment命令式创建(陈述式创建)
查看pod详细信息
访问测试
所有资源查看
删除陈述式创建的pod
kubectl delete deployments.apps webserver
删除pod
service是一个抽象概念,定义了一个服务的多个pod逻辑合集和访问pod的策略,一般把service称为微服务。
创建service
kubectl expose deployment nginx --port=80 --target-port=80
此时pod客户端可以通过service的名称访问后端的两个Pod
ClusterIP: 默认类型,自动分配一个仅集群内部可以访问的虚拟IP
使用NodePort类型暴露端口,让外部客户端访问Pod
kubectl edit svc nginx #修改service的type为NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort #也可以在创建service时指定类型
访问测试,说明创建成功
更详细信息的查看
删除其中一个结点,再次查看结点信息会发现有新的结点补上来
Pod扩容与缩容
kubectl scale --replicas=6 deployment nginx
kubectl scale --replicas=3 deployment nginx
查看pod详细信息,也就是可以查看pod具体运行在哪个节点上(ip地址信息)
连接三个副本可以分别查看到其ip
查看资源清单
pod的扩容,结点数添加到6
查看所有资源信息
更新pod镜像
kubectl set image deployment nginx nginx=nginx:1.16.0 --record
更新pod镜像后发现pod的三个id都换成了新的,说明镜像更新成功
pod回滚
kubectl rollout history deployment nginx #查看历史版本
kubectl rollout undo deployment nginx --to-revision=1 #回滚并设置回滚后的版本
查看pod内容
查看所有资源信息
删除旧版本资源
再次查看所有的资源清单
二、资源清单
在kubernetes中,一般使用yaml格式的文件来创建符合我们预期的pod,这样的yaml文件一般称为资源清单;什么叫资源?kubernetes中所有的内容都抽象为资源,资源实例化之后叫做对象
在kubernetes中有哪些资源?
- 工作负载型资源(workload):Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob(ReplicationController在v1.11版本被废弃)
- 服务发现及负载均衡型资源(ServiceDiscovery LoadBalance):Service、Ingress、…
- 配置与存储型资源:Volume(存储卷)、CSI(容器存储接口,可以扩展各种各样的第三方存储卷)
- 特殊类型的存储卷:ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感数据)、DownwardAPI(把外部环境中的信息输出给容器)
以上这些资源都是配置在命名空间级别
- 集群级资源:Namespace、Node、Role、ClusterRole、RoleBinding(角色绑定)、ClusterRoleBinding(集群角色绑定)
- 元数据型资源:HPA(Pod水平扩展)、PodTemplate(Pod模板,用于让控制器创建Pod时使用的模板)、LimitRange(用来定义硬件资源限制的)
格式如下:
apiVersion: group/version #指明api资源属于哪个群组和版本,同一个组可以有多个版本
kubectl api-versions #查询命令
kind: #标记创建的资源类型,k8s主要支持以下资源类别
Pod,ReplicaSet,Deployment,StatefulSet,DaemonSet,Job,Cronjob
metadata: #元数据
name: #对像名称
namespace: #对象属于哪个命名空间
labels: #指定资源标签,标签是一种键值数据
spec: #定义目标资源的期望状态
kubectl explain pod #查询帮助文档
主要参数名 | 字段类型 | 说明 |
version | String | 这里指的是K8S API的版本,目前基本上v1,可以用kubectl api-version命令查询 |
kind | String | 这里指的是yaml文件定义的资源类型和角色,例如Pod |
metadata | Object | 元数据的对象,固定直就是metadata |
metadata.name | String | 元数据对象的名字,这里由我们自己填写,比如Pod的名字 |
metadata.namespace | String | 元数据对象的命名空间,自定义 |
Spec | Object | 详细定义对象,固定直就写Spec |
spec.containers[] | list | Spec对象的容器列表定义,是列表类型 |
spec.containers[].name | String | 定义容器的名字 |
spec.containers[].image | String | 定义要用到的镜像名称 |
检查确保harbor仓库完好
server11:
cd harbor/
docker-compose start
docker-compose ps
添加语句到文件中
vim .bash_profile
export KUBECONFIG=/etc/kubernetes/admin.conf
这样做不用每次重启系统都要再添加一次结点
检查结点是否完好(注意要将结点主机开启,否则结点主机状态会显示not ready)
自主式Pod资源清单
mkdir Pod
cd Pod
ls
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
containers:
- name: nginx
image: nginx
---
kubectl apply -f pod.yaml
kubectl get pod
编写pod文件并应用,查看pod内容
查看pod的非常详细的信息
回收新建的pod
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
containers:
- name: nginx
image: nginx
- name: busybox
image: busyboxplus
stdin: true
tty: true
---
kubectl apply -f pod.yaml
kubectl get pod
两个容器再pod中,进入pod发现默认两个容器都进入,但是写在文件前面的先出现
-c 容器名指定进入某一容器,但两个容器之间人然可以通信
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
containers:
- name: nginx
image: nginx
- name: busybox
image: nginx
---
kubectl apply -f pod.yaml
kubectl get pod
发现刚开始报错,之后运行成功
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:g
name: pod-example
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
hostPort: 80
containerPort: 80 #指定端口
---
kubectl apply -f pod.yaml
kubectl get pod
在分配到的结点主机测试发现没有80端口的服务
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
hostPort: 80
containerPort: 80
resources:
limits: #编写资源的限制条件
cpu: 0.5
memory: 200Mi
requests:
cpu: 0.2
memory: 100Mi
---
kubectl apply -f pod.yaml
kubectl get pod
kubectl describe get pod 'podname'
通过修改文件可以修改pod的结点主机
标签
kubectl get pod --show-labels #查看标签
kubectl get pod -l app #过滤包含app的标签
kubectl get pod -L app
kubectl label pod demo version=v1 #打标签
kubectl get pod --show-labels
kubectl label pod demo app=nginx --overwrite #更改标签
查看结点主机的标签内容,复制需要修改主机的标签内容
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
nodeSelector:
kubernetes.io/hostname: server13
hostNetwork: true
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
hostPort: 80
containerPort: 80
resources:
limits:
cpu: 0.5
memory: 200Mi
requests:
cpu: 0.2
memory: 100Mi
---
kubectl apply -f pod.yaml
kubectl get pod -o wide
查看结点主机,发现已经变化为server13
server13:
iptables -t nat -nL | grep :80
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
nodeSelector:
disktype: ssd
hostNetwork: true
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
hostPort: 80
containerPort: 80
resources:
limits:
cpu: 0.5
memory: 200Mi
requests:
cpu: 0.2
memory: 100Mi
---
kubectl apply -f pod.yaml
kubectl get pod -o wide
kubectl describe pod pod-example
节点标签选择器
kubectl label nodes server2 disktype=ssd
kubectl get nodes -l disktype
三、Pod生命周期
- Pod 可以包含多个容器,应用运行在这些容器里面,同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
- Init 容器与普通的容器非常像,除了如下两点: 它们总是运行到完成。 Init 容器不支持 Readiness,因为它们必须在 Pod
就绪之前运行完成,每个 Init 容器必须运行成功,下一个才能够运行。 - 如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。然而,如果 Pod
对应的 restartPolicy 值为 Never,它不会重新启动。
vim init.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh','-c','echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox
command: ["sh", "-c", "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
---
kubectl apply -f init.yaml
kubectl get pod #发现还在初始化
vim service.yaml
---
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 80
---
kubectl apply -f service.yaml
kubectl get pod
应用了init.yaml文件后,pod一直处于初始化阶段,不能完成running
应用service文件后,pod运行正常
探针
探针 是由 kubelet 对容器执行的定期诊断:
- ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
- HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于400,则诊断被认为是成功的。
探针包括存活探针和就绪探针
- 存活探针:查看应用是否还活着,若死了则会删除原来的应用,创建新的应用来顶替该应用,防止系统中有僵死态的应用进程出现
- 就绪探针:了解应用是否为流量的到来做好准备,若准备好才会分配服务并将流量发送到Pod
每次探测都将获得以下三种结果之一:
- 成功:容器通过了诊断。
- 失败:容器未通过诊断。
- 未知:诊断失败,因此不会采取任何行动。
liveness实例
kubectl exec -it liveness-http -- bash
root@liveness-http:/# cd /usr/local/nginx/html/
bash: cd: /usr/local/nginx/html/: No such file or directory
root@liveness-http:/# cd /usr/share/nginx/html/
root@liveness-http:/usr/share/nginx/html# ls
50x.html index.html
root@liveness-http:/usr/share/nginx/html# echo testpage > test.html
kubectl exec -it liveness-http -- rm -f /usr/share/nginx/html/test.html
运行后发现没有完全运行
进入容器并在nginx的发布目录中编写新的test.html文件
再次查看pod的运行情况,发现可以运行
-w 是watch监控的意思,可以看到pod动态的变化
查看pod的ip
访问ip下的test文件,访问成功,出现我们写进去的内容
删除容器中的test文件,再次访问ip下的test发现显示404
kubectl describe pod liveness-http
查看朝详细信息发现也是404错误
四、今日报错
缺少containerPort的领域,则需要在资源清单中添加
vim pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
nodeSelector:
disktype: ssd
hostNetwork: true
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
hostPort: 80
containerPort: 80
---
再次应用发现应用成功,漂亮阿老哥!