k8s自主式pod之应用策略规则

自主式pod应用

我们接触的pod大多数是控制器控制的pod,那么今天讲的是自主式pod(也就是由yaml文件来创建的pod),也就是pod自己去控制自己,防止pod被控制器杀死。

1,首先我们来创建一个nginx的pod资源对象:

在创建pod之前,我们来查看一下镜像的下载策略:

[[email protected] yaml]# kubectl explain pod.spec.containers
查看imagePullpolicy的策略字段:
   imagePullPolicy  <string>
     Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always
     if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated.
     More info:
     https://kubernetes.io/docs/concepts/containers/images#updating-images

几种策略解释:

  • Always:镜像标签为“latest”或镜像标签不存在的时候,总是在从指定的仓库(Dockerhub)中获取镜像。
    目前 Docker 官方维护了一个公共仓库 Docker Hub,其中已经包括了数量超过 2,650,000 的镜像。大部分需求都可以通过在 Docker Hub 中直接下载镜像来实现。
  • Nerver:禁止从仓库中下载镜像,也就是说只使用本地镜像。如果本地也没有镜像,则pod将无法运行。
  • IfNotPresent(提供):仅当本地没有对应镜像时,才从目标仓库中下载。

默认的获取策略如下:
镜像标签为“latest”,它的默认下载策略是Always。
镜像标签为自定义(不是默认的latest),它的默认下载策略是IfNotPresent。

//创建一个pod(定义某种策略):

[[email protected] yaml]# vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: myapp
    image: nginx
    imagePullPolicy: Always        #定义镜像下载策略(从指定仓库获取镜像)
    ports:
      - containerPort: 80                  #暴露容器的端口
//执行yaml文件:
[[email protected] yaml]# vim test-pod.yaml
[[email protected] yaml]# kubectl  apply -f test-pod.yaml 
//查看pod的状态:
[[email protected] yaml]# kubectl  get pod test-pod -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE     NOMINATED NODE   READINESS GATES
test-pod   1/1     Running   0          7m55s   10.244.2.2   node02   <none>           <none>
//以json格式查看pod的一个详细信息:
[[email protected] yaml]# kubectl  get pod test-pod -o json


image镜像相位(状态):

  • Running:Pod所需的容器已经被成功调度到某个节点,且已经成功运行。
  • Pending:APIserver创建了pod资源对象,并且已经存入etcd中,但它尚未被调度完成或者仍然处于仓库中下载镜像的过程。
  • Succeeded:Pod中的所有容器已成功终止,并且不会重新启动。
  • Failed:Pod中的所有容器均已终止,并且至少一个容器因故障而终止。也就是说,容器要么以非零状态退出,要么被系统终止
  • Unknown:APIserver无法正常获取到pod对象的状态,通常用于其无法与所在工作节点的kubelet通信所致。

一定要熟悉并且记住这几种状态,因为这有利于在集群出现故障时能够准确的找到问题,且快速的排查错误。


2,pod的重启策略:

//首先我们查看pod的一个重启策略:
[[email protected] yaml]# kubectl  explain  pod.spec  #查看pod的spec字段的重启策略

  • 字段解释:
  • Always:但凡是pod对象终止就重启,此为默认策略。
  • OnFailure:仅在pod对象出现错误时才重启,如果容器是处于complete状态,也就是正常退出的状态,是不会重启的。
  • Never:从不重启。

3,我们模拟一下,创建一个pod,使用公司内部的私有仓库中的镜像,其镜像下载策略为:Never(使用本地镜像),pod的重启策略为Never(从不重启)。

[[email protected] yaml]# vim nginx-pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  labels:                           #定义标签与servic相关联
    test: myweb
spec:
  restartPolicy: Never     #定义镜像重启策略为Never
  containers:
  - name: myweb
    image: 172.16.1.30:5000/nginx:v1
    imagePullPolicy: Never         #定义镜像下载策略为Never
---
apiVersion: v1
kind: Service
metadata:
  name: mynginx
spec:
  type: NodePort
  selector:
    test: myweb
  ports:
  - name: nginx
    port: 8080           #定义Cluster IP端口
    targetPort: 80      #暴露容器端口
    nodePort: 30000         #定义给外网通过宿主机暴露的端口
[[email protected] yaml]# kubectl  apply -f nginx-pod1.yaml
pod/mynginx created
service/mynginx created

//查看pod当前状态:

查看pod信息可以看到镜像拉取失败,所以我们查看该pod的详细信息进行排查:
[[email protected] yaml]# kubectl describe pod mynginx

可以看到是策略的原因,Nerver策略只能从该节点的本地镜像进行下载,所以我们需要在该节点(node02)上将私有仓库中的镜像进行拉取到本地。

[[email protected] ~]# docker pull 172.16.1.30:5000/nginx:v1
v1: Pulling from nginx
Digest: sha256:189cce606b29fb2a33ebc2fcecfa8e33b0b99740da4737133cdbcee92f3aba0a
Status: Downloaded newer image for 172.16.1.30:5000/nginx:v1
//回到master,再次查看pod1是否运行:
[[email protected] yaml]# kubectl  get pod -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE     NOMINATED NODE   READINESS GATES
mynginx    1/1     Running   0          7m32s   10.244.2.4   node02   <none>           <none>
test-pod   1/1     Running   1          7h10m   10.244.2.3   node02   <none>           <none>

2)测试pod重启策略:
我们模拟pod非正常退出

[[email protected] yaml]# vim nginx-pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  labels:
    test: myweb
spec:
  restartPolicy: Never
  containers:
  - name: myweb
    image: 172.16.1.30:5000/nginx:v1
    imagePullPolicy: Never
    args: [/bin/sh -c sleep 10; exit 1]    #添加args字段,模拟sleep10秒后退出
//重新启动pod
[[email protected] yaml]# kubectl  delete -f  nginx-pod1.yaml
pod "mynginx" deleted
service "mynginx" deleted
[[email protected] yaml]# kubectl  apply -f  nginx-pod1.yaml
pod/mynginx created
service/mynginx created

PS:因为在pod的文件中设置了pod的重启策略为Never,所以在无法修改策略的情况下,需要将该pod删除,重新执行yaml文件生成新的pod。

//第一次查看pod状态:

看到新的pod再node01节点上,所以我们还需再node01上将镜像拉取到本地。

[[email protected] ~]# docker pull 172.16.1.30:5000/nginx:v1
v1: Pulling from nginx
Digest: sha256:189cce606b29fb2a33ebc2fcecfa8e33b0b99740da4737133cdbcee92f3aba0a
Status: Downloaded newer image for 172.16.1.30:5000/nginx:v1

为了更好的查看到效果,我们重新执行yaml文件,生成新pod:
[[email protected] yaml]# kubectl delete -f nginx-pod1.yaml
[[email protected] yaml]# kubectl apply -f nginx-pod1.yaml

//查看pod的最终状态:

我们来查看该pod的详细信息(查看pod运行失败的原因):
[[email protected] yaml]# kubectl  describe  pod mynginx 


从上面的信息中我们可以得知pod在创建出容器后,却非正常退出了,最后导致容器创建失败。

3)我们修改策略规则,将规则设置为OnFailure:

//重新运行pod:
[[email protected] yaml]# kubectl delete -f  nginx-pod1.yaml
pod "mynginx" deleted
service "mynginx" deleted
[[email protected] yaml]# kubectl apply -f  nginx-pod1.yaml
pod/mynginx created
service/mynginx created
查看pod状态(失败):
[[email protected] yaml]# kubectl  get pod -o wide
NAME      READY   STATUS              RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mynginx   0/1     RunContainerError   3          55s   10.244.2.8   node02   <none>           <none>

[[email protected] yaml]# kubectl get pod -o json


我们可以看到当前pod创建容器失败。

//我们马上实时监控pod当前的状态:

可以看到pod一直在不停的重启,原因是我们在设置pod重启为OnFailure时,同时设置了pod在睡眠10秒后,便会重启,所以该pod会一直重启下去。

4)我们修改策略规则,并将其pod恢复正常运行

//重新运行yaml文件,生成新的pod:
[[email protected] yaml]# kubectl  delete -f  nginx-pod1.yaml
pod "mynginx" deleted
service "mynginx" deleted
k[[email protected] yaml]# kubectl  apply -f  nginx-pod1.yaml
pod/mynginx created
service/mynginx created
//查看pod是否恢复正常运行:(正常运行)
[[email protected] yaml]# kubectl  get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mynginx   1/1     Running   0          71s   10.244.1.8   node01   <none>           <none>

5) 查看servie信息,验证nginx的web界面能否正常访问:

[[email protected] yaml]# kubectl  get svc  mynginx
NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
mynginx   NodePort   10.101.131.36   <none>        8080:30000/TCP   4m23s

———————— 本文至此结束,感谢阅读 ————————

原文地址:https://blog.51cto.com/13972012/2456490

时间: 2024-10-07 15:52:27

k8s自主式pod之应用策略规则的相关文章

k8s实践4:kube-proxy问题iptables转发规则不显示

1.今天想看看kube-proxy的iptables转发规则,执行命令iptables-save,见下: [root@k8s-master1 test]# iptables-save |grep "^-A KUBE" -A KUBE-FIREWALL -m comment --comment "kubernetes firewall for dropping marked packets" -m mark --mark 0x8000/0x8000 -j DROP -

k8s学习 - 概念 - Pod

k8s学习 - 概念 - Pod 这篇继续看概念,主要是 Pod 这个概念,这个概念非常重要,是 k8s 集群的最小单位. 怎么才算是理解好 pod 了呢,基本上把 pod 的所有 describe 和配置文件的配置项都能看懂就算是对 pod 比较了解了. Pod 我们通过调用一个kubectl describe pod xxx 可以查看某个 pod 的具体信息. describe 的信息我们用注释的形式来解读. Name: task-pv-pod Namespace: default // 没

k8s的调度器架构和策略

调度器功能 默认调度器的主要职责,就是为一个新创建出来的Pod寻找一个最合适的节点(Node) 调度器对一个 Pod 调度成功,实际上就是将它的 spec.nodeName 字段填上调度结果的节点名字 预选节点 从集群所有的节点中,根据调度算法挑选出所有可以运行该 Pod 的节点默认调度器会首先调用一组叫作 Predicate 的调度算法,来检查每个Node 优选节点 从预选的结果中,再根据调度算法挑选一个最符合条件的节点作为最终结果.再调用一组叫作 Priority 的调度算法,来给上一步得到

关于VS2010出现“此方法显式使用的 CAS 策略已被 .NET Framework 弃用... ...请使用 NetFx40_LegacySecurityPolicy 配置开关”解决办法

有时候VS会出现“此方法显式使用的 CAS 策略已被 .NET Framework 弃用.若要出于兼容性原因而启用 CAS 策略,请使用 NetFx40_LegacySecurityPolicy 配置开关.这样的错误,在网上找过很多解决办法其中修改配置文件最管用了,下面说一下怎么改配置文件 首先找到VS2010的安装目录,默认是 C:\Program Files\Microsoft Visual Studio 10.0 然后在 C:\Program Files\Microsoft Visual

此方法显式使用的 CAS 策略已被 .NET Framework 弃用。若要出于兼容性原因而启用 CAS 策略,请使用 NetFx40_LegacySecurityPolicy 配置开关

使用DEV8.3winform控件,框架从.net2.0升级到4.0后,程序报错,调用的目标异常. 此方法显式使用的 CAS 策略已被 .NET Framework 弃用.若要出于兼容性原因而启用 CAS 策略,请使用 NetFx40_LegacySecurityPolicy 配置开关.有关详细信息,请参见 http://go.microsoft.com/fwlink/?LinkID=155570. 在 System.Security.SecurityManager.ResolvePolicy(

Kafka 自定义指定消息partition策略规则及DefaultPartitioner源码分析

Kafka 自定义指定消息partition策略规则及DefaultPartitioner源码分析 一.概述 kafka默认使用DefaultPartitioner类作为默认的partition策略规则,具体默认设置是在ProducerConfig类中(如下图) 二.DefaultPartitioner.class 源码分析 1.类关系图 2.源码分析 public class DefaultPartitioner implements Partitioner { //缓存map key->to

k8s中的pod控制器之Deployment、DaemonSet、StatefulSet

pod控制器分类:1.ReplicationController2.ReplicaSet3.Deployment4.StatefulSet5.DaemonSet6.Job,Cronjob7.HPApod控制器:一般包括3部分1.标签选择器2.期望的副本数(DaemonSet控制器不需要)3.pod模板deploy控制器构建于rs控制器之上,新特性包括:1.事件和状态查看2.回滚3.版本记录4.暂停和启动5.支持两种自动更新方案Recreate删除重建RollingUpdate回滚升级(默认方式)

K8S调度之pod亲和性

[toc] Pod Affinity 通过<K8S调度之节点亲和性>,我们知道怎么在调度的时候让pod灵活的选择node,但有些时候我们希望调度能够考虑pod之间的关系,而不只是pod与node的关系.于是在kubernetes 1.4的时候引入了pod affinity. 为什么有这样的需求呢?举个例子,我们系统服务 A 和服务 B 尽量部署在同个主机.机房.城市,因为它们网络沟通比较多:再比如,我们系统数据服务 C 和数据服务 D 尽量分开,因为如果它们分配到一起,然后主机或者机房出了问题

linux防火墙的策略规则

介绍: 防火墙默认有四表五链 四表:(表的优先级:raw > mangle > nat > filter ) 1.Raw表--两个链:PREROUTING.OUTPUT 作用:决定数据包是否被状态跟踪机制处理  内核模块:iptable_raw 2.Mangle表--五个链:PREROUTING.POSTROUTING.INPUT.OUTPUT.FORWARD 作用:修改数据包的服务类型.TTL.并且可以配置路由实现QOS内核模块:iptable_mangle 3.Nat表--三个链:P