首页 > 其他分享 >k8s学习手册

k8s学习手册

时间：2022-11-29 09:11:39浏览次数：72  
标签：容器 name kubectl 手册 学习 nginx Pod k8s pod

k8s学习手册

k8s学习手册

原理讲解

1、Master和Node

1）、Master

K8S中的Master是集群控制节点，负责整个集群的管理和控制

在Master上运行着以下关键进程：

  • kube-apiserver：提供了HTTP Rest接口的关键服务进程，是K8S里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程

  • kube-controller-manager：K8S里所有资源对象的自动化控制中心，集群内各种资源Controller的核心管理者，针对每一种资源都有相应的Controller，保证其下管理的每个Controller所对应的资源始终处于期望状态

  • kube-scheduler：负责资源调度（Pod调度）的进程，通过API Server的Watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最合适的Node

  • etcd：K8S里的所有资源对象以及状态的数据都被保存在etcd中

2）、Node

Node是K8S集群中的工作负载节点，每个Node都会被Master分配一些工作负载，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上

在每个Node上都运行着以下关键进程：

kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能

kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件

Docker Engine：Docker引擎，负责本机的容器创建和管理工作

在默认情况下Kubelet会向Master注册自己，一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的信息（例如机器的CPU和内存情况以及有哪些Pod在运行等），这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为失败，Node的状态被标记为不可用，随后Master会触发工作负载转移的自动流程

 

2、Pod

每个Pod都有一个根容器的Pause容器，还包含一个或多个紧密相关的用户业务容器

Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume。在K8S里，一个Pod里的容器与另外主机上的Pod容器能够直接通信

Pod有两种类型：普通的Pod及静态Pod（Static Pod）。后者并没被存放在K8S的etcd存储里，而是被存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动、运行。而普通的Pod一旦被创建，就会被放入etcd中存储，随后会被K8S的Master调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下，当Pod里的某个容器停止时，K8S会自动检测到这个问题并且重新启动这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，就会将这个Node上的所有Pod重新调度到其他节点上

3、K8S创建一个Pod的流程

1）、用户提交创建Pod的请求，可以通过API Server的REST API，也可用Kubectl命令行工具

2）、API Server处理用户请求，存储Pod数据到etcd

3）、Schedule通过和API Server的watch机制，查看到新的Pod，尝试为Pod绑定Node

4）、过滤主机：调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源，那么就要过滤掉资源不够的主机

5）、主机打分：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等

6）、选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中

7）、Kubelet根据调度结果执行Pod创建操作： 绑定成功后，会启动container，Scheduler会调用API在数据库etcd中创建一个bound pod对象，描述在一个工作节点上绑定运行的所有Pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息，一旦发现应该在该工作节点上运行的bound pod对象没有更新，则调用Docker API创建并启动Pod内的容器

在这期间，Control Manager同时会根据K8S的mainfiles文件执行RC Pod的数量来保证指定的Pod副本数。而其他的组件，比如Scheduler负责Pod绑定的调度，从而完成整个Pod的创建

 

windows k8s安装

  1. 获取win版安装脚本，开源地址仓库 GitHub - AliyunContainerService/k8s-for-docker-desktop: 为Docker Desktop for Mac/Windows开启Kubernetes和Istio。

拉取代码git clone [email protected]:AliyunContainerService/k8s-for-docker-desktop.git

  • 执行代码目录load_images.ps1脚本获取镜像，用Windows PowerShell管理方式执行

  • 拉取镜像过程中犹豫镜像在国外所以需要配置代理，docker设置如下:

代理配置参数: "registry-mirrors": [

"https://nv3cpi2l.mirror.aliyuncs.com"

]

 

2、本地docker desktop开启k8s

直接点击安装即可

安装成功后的状态如下:

3、安装k8s管理工具

  • 下载当前管理工具编排yaml文件 dashboard.yaml

  • 执行命令 kubectl apply -f dashboard.yaml，在执行kubectl proxy

  • 访问http://127.0.0.1:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

  • 点击跳过即可

4、运行第一个k8s程序

  • 下载nginx 编排文件nginx.yaml

  • 执行命令部署 kubectl apply -f nginx.yaml

  • 访问http://localhost:30009/ nginx部署成功

容器编排与作业管理

1、Pod

  1. 为啥需要pod

linux下执行 pstree -g 命令：

 


systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
           | `-{gmain}(1984)
           |-acpid(2044)
          ...      
           |-lxcfs(1936)-+-{lxcfs}(1936)
           | `-{lxcfs}(1936)
           |-mdadm(2135)
           |-ntpd(2358)
           |-polkitd(2128)-+-{gdbus}(2128)
           | `-{gmain}(2128)
           |-rsyslogd(1632)-+-{in:imklog}(1632)
           |  |-{in:imuxsock) S 1(1632)
           | `-{rs:main Q:Reg}(1632)
           |-snapd(1942)-+-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)
           |  |-{snapd}(1942)

 

不难发现，在一个真正的操作系统里，进程并不是“孤苦伶仃”地独自运行的，而是以进程组的方式，“有原则地”组织在一起。比如，这里有一个叫作 rsyslogd 的程序，它负责的是 Linux 操作系统里的日志处理。可以看到，rsyslogd 的主程序 main，和它要用到的内核日志模块 imklog 等，同属于 1632 进程组。这些进程相互协作，共同完成 rsyslogd 程序的职责。

而 Kubernetes 项目所做的，其实就是将“进程组”的概念映射到了容器技术中，并使其成为了这个云计算“操作系统”里的“一等公民”

  1. 假设我们的 Kubernetes 集群上有两个节点：node-1 上有 3 GB 可用内存，node-2 有 2.5 GB 可用内存。这时，假设我要用 Docker Swarm 来运行这个 rsyslogd 程序。为了能够让这三个容器都运行在同一台机器上，我就必须在另外两个容器上设置一个 affinity=main（与 main 容器有亲密性）的约束，即：它们俩必须和 main 容器运行在同一台机器上。然后，我顺序执行：“docker run main”“docker run imklog”和“docker run imuxsock”，创建这三个容器。这样，这三个容器都会进入 Swarm 的待调度队列。然后，main 容器和 imklog 容器都先后出队并被调度到了 node-2 上（这个情况是完全有可能的）。可是，当 imuxsock 容器出队开始被调度时，Swarm 就有点懵了：node-2 上的可用资源只有 0.5 GB 了，并不足以运行 imuxsock 容器；可是，根据 affinity=main 的约束，imuxsock 容器又只能运行在 node-2 上。这就是一个典型的成组调度（gang scheduling）没有被妥善处理的例子。

这个问题在学术界用了各种方案来解决，都没妥善的解决，但是，到了 Kubernetes 项目里，这样的问题就迎刃而解了：Pod 是 Kubernetes 里的原子调度单位。这就意味着，Kubernetes 项目的调度器，是统一按照 Pod 而非容器的资源需求进行计算的。所以，像 imklog、imuxsock 和 main 函数主进程这样的三个容器，正是一个典型的由三个容器组成的 Pod。Kubernetes 项目在调度时，自然就会去选择可用内存等于 3 GB 的 node-1 节点进行绑定，而根本不会考虑 node-2。

像这样容器间的紧密协作，我们可以称为“超亲密关系”。这些具有“超亲密关系”容器的典型特征包括但不限于：互相之间会发生直接的文件交换、使用 localhost 或者 Socket 文件进行本地通信、会发生非常频繁的远程调用、需要共享某些 Linux Namespace（比如，一个容器要加入另一个容器的 Network Namespace）等等。

  1. 不过，Pod 在 Kubernetes 项目里还有更重要的意义，那就是：容器设计模式。首先，关于 Pod 最重要的一个事实是：它只是一个逻辑概念。

也就是说，Kubernetes 真正处理的，还是宿主机操作系统上 Linux 容器的 Namespace 和 Cgroups，而并不存在一个所谓的 Pod 的边界或者隔离环境。

那么，Pod 又是怎么被“创建”出来的呢？答案是：Pod，其实是一组共享了某些资源的容器。

具体的说：Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。

那这么来看的话，一个有 A、B 两个容器的 Pod，不就是等同于一个容器（容器 A）共享另外一个容器（容器 B）的网络和 Volume 的玩儿法么？

这好像通过 docker run --net --volumes-from 这样的命令就能实现嘛，比如：

 

这好像通过 docker run --net --volumes-from 这样的命令就能实现嘛，比如：

 

但是，你有没有考虑过，如果真这样做的话，容器 B 就必须比容器 A 先启动，这样一个 Pod 里的多个容器就不是对等关系，而是拓扑关系了。

所以，在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。这样的组织关系

如上图所示，这个 Pod 里有两个用户容器 A 和 B，还有一个 Infra 容器。很容易理解，在 Kubernetes 项目里，Infra 容器一定要占用极少的资源，所以它使用的是一个非常特殊的镜像，叫作：k8s.gcr.io/pause。这个镜像是一个用汇编语言编写的、永远处于“暂停”状态的容器，解压后的大小也只有 100~200 KB 左右。

而在 Infra 容器“Hold 住”Network Namespace 后，用户容器就可以加入到 Infra 容器的 Network Namespace 当中了。所以，如果你查看这些容器在宿主机上的 Namespace 文件（这个 Namespace 文件的路径，我已经在前面的内容中介绍过），它们指向的值一定是完全一样的。

这也就意味着，对于 Pod 里的容器 A 和容器 B 来说：

  • 它们可以直接使用 localhost 进行通信；

  • 它们看到的网络设备跟 Infra 容器看到的完全一样；

  • 一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP 地址；

  • 当然，其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享；Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。

而对于同一个 Pod 里面的所有用户容器来说，它们的进出流量，也可以认为都是通过 Infra 容器完成的。这一点很重要，因为将来如果你要为 Kubernetes 开发一个网络插件时，应该重点考虑的是如何配置这个 Pod 的 Network Namespace，而不是每一个用户容器如何使用你的网络配置，这是没有意义的。

有了这个设计之后，共享 Volume 就简单多了：Kubernetes 项目只要把所有 Volume 的定义都设计在 Pod 层级即可。这样，一个 Volume 对应的宿主机目录对于 Pod 来说就只有一个，Pod 里的容器只要声明挂载这个 Volume，就一定可以共享这个 Volume 对应的宿主机目录。

明白了 Pod 的实现原理后，我们再来讨论“容器设计模式”，就容易多了。

Pod 这种“超亲密关系”容器的设计思想，实际上就是希望，当用户想在一个容器里跑多个功能并不相关的应用时，应该优先考虑它们是不是更应该被描述成一个 Pod 里的多个容器。

为了能够掌握这种思考方式，你就应该尽量尝试使用它来描述一些用单个容器难以解决的问题。

举例1：

 

 


apiVersion: v1
kind: Pod
metadata:
  name: javaweb-2
spec:
  initContainers:
  - image: geektime/sample:v2
    name: war
    command: ["cp", "/sample.war", "/app"]
    volumeMounts:
    - mountPath: /app
      name: app-volume
  containers:
  - image: geektime/tomcat:7.0
    name: tomcat
    command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
    volumeMounts:
    - mountPath: /root/apache-tomcat-7.0.42-v2/webapps
      name: app-volume
    ports:
    - containerPort: 8080
      hostPort: 8001 
  volumes:
  - name: app-volume
    emptyDir: {}

 

 

举例2：dapr的边车模式，一个pod运行程序和边车 网络互通

 

  1. pod 命令和实践

2.1、yaml文件编写

 

apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中  
kind: Pod #指定创建资源的角色/类型  
metadata: #资源的元数据/属性  
  name: web04-pod #资源的名字，在同一个namespace中必须唯一  
  labels: #设定资源的标签，详情请见附录：1、标签
    k8s-app: apache  
    version: v1  
    kubernetes.io/cluster-service: "true"  
  annotations:            #自定义注解列表  
    - name: String        #自定义注解名字  
spec:#specification of the resource content 指定该资源的内容  
  restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器  
  nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1  
    zone: node1  
  containers:  
  - name: web04-pod #容器的名字  
    image: web:apache #容器使用的镜像地址  
    imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，
                           # Always，每次都检查
                           # Never，每次都不检查（不管本地是否有）
                           # IfNotPresent，如果本地有就不检查，如果没有就拉取
    command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT  
    args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数  
    env: #指定容器中的环境变量  
    - name: str #变量的名字  
      value: "/etc/run.sh" #变量的值  
    resources: #资源管理，详情请见 附录2、资源管理
      requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行  
        cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
        memory: 32Mi #内存使用量  
      limits: #资源限制  
        cpu: 0.5  
        memory: 32Mi  
    ports:  
    - containerPort: 80 #容器开发对外的端口
      name: httpd  #名称
      protocol: TCP  
    livenessProbe: #pod内容器健康检查的设置，详情请见,附录3、应用程序健康检查
      httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常  
        path: / #URI地址  
        port: 80  
        #host: 127.0.0.1 #主机地址  
        scheme: HTTP  
      initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始  
      timeoutSeconds: 5 #检测的超时时间  
      periodSeconds: 15  #检查间隔时间  
      #也可以用这种方法  
      #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常  
      #  command:  
      #    - cat  
      #    - /tmp/health  
      #也可以用这种方法  
      #tcpSocket: //通过tcpSocket检查健康   
      #  port: number   
    lifecycle: #生命周期管理  
      postStart: #容器运行之前运行的任务  
        exec:  
          command:  
            - 'sh'  
            - 'yum upgrade -y'  
      preStop:#容器关闭之前运行的任务  
        exec:  
          command: ['service httpd stop']  
    volumeMounts:  #详情请见http://blog.csdn.net/liyingke112/article/details/76577520
    - name: volume #挂载设备的名字，与volumes[*].name 需要对应    
      mountPath: /data #挂载到容器的某个路径下  
      readOnly: True  
  volumes: #定义一组挂载设备  
  - name: volume #定义一个挂载设备的名字  
    #meptyDir: {}  
    hostPath:  
      path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种

 

2.2、pod相关命令

  1. 创建pod

kubectl create -f pod.yaml 创建pod

使用yaml创建pod时可以使用creat或者apply

apply：使用apply时，如果pod已存在相当于执行更新操作

  1. 查看pod

  • kubectl get pod 查看所有

  • kubectl get pod|grep nginx1 查看 nginx1的pod

  • kubectl get pod -n default 查看指定命名空间下的pod,不指定namespace,默认是名为default的namespace

  • kubectl get pod -o wide 查看pod详细信息-o wide

  • kubectl describe pod pod-stress [-n namespace pod在非默认空间时需要指定pod所在的namespace] 描述pod详细信息

  • kubectl delete pod nginx 命令行直接删除

  • kubectl delete -f pod.yaml 使用yaml资源清单文件删除

  • kubectl delete ns test 删除某个namespace会直接删除该命名空间下所有的pod

  • kubectl get pod |awk 'NR >1 {print $1}' |xargs kubectl delete pod 命令行删除，后面直接跟多个要删除的pod名称

  • kubectl get pod --show-labels 查看pod标签

  • kubectl label pod nginx1 env=test zone=beijing 通过命令行设置标签

  • yaml文件设置标签

 

apiVersion: v1
kind: Pod
metadata:
  name: nginx2
  labels:
    env: dev
    zone: A
spec:
  containers:
    - name: nginx
      image: nginx

 

  • kubectl get pod -l env=dev 通过等值关系查看标签

  • kubectl get pod -l "env in(dev,test,prod)" 通过集合关系查看标签

  • kubectl label pod nginx1 env- zone- 删除pod标签

  • Pod内部镜像操作命令

其他命令

# 部署应用

kubectl apply -f app.yaml

# 查看 deployment

kubectl get deployment

# 查看 pod

kubectl get pod -o wide

# 查看 pod 详情

kubectl describe pod pod-name

# 查看 log

kubectl logs pod-name

# 进入 Pod 容器终端， -c container-name 可以指定进入哪个容器。

kubectl exec -it pod-name -- bash

# 伸缩扩展副本

kubectl scale deployment test-k8s --replicas=5

# 把集群内端口映射到节点

kubectl port-forward pod-name 8090:8080

# 查看历史

kubectl rollout history deployment test-k8s

# 回到上个版本

kubectl rollout undo deployment test-k8s

# 回到指定版本

kubectl rollout undo deployment test-k8s --to-revision=2

# 删除部署

kubectl delete deployment test-k8s

# 查看全部

kubectl get all

# 重新部署

kubectl rollout restart deployment test-k8s

# 命令修改镜像，--record 表示把这个命令记录到操作历史中

kubectl set image deployment test-k8s test-k8s=ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v2-with-error --record

# 暂停运行，暂停后，对 deployment 的修改不会立刻生效，恢复后才应用设置

kubectl rollout pause deployment test-k8s

# 恢复

kubectl rollout resume deployment test-k8s

# 输出到文件

kubectl get deployment test-k8s -o yaml >> app2.yaml

# 删除全部资源

kubectl delete all --all

不用交互直接操作名

  • 命令格式：kubectl exec pod名 -c 容器名 -- 命令

  • 不指定容器名,则默认为pod里的第1个容器

kubectl exec nginx1 -- date

和容器交互操作

 

kubectl exec -it nginx1 -c nginx -- /bin/bash
root@nginx1:/# ls
bin  boot  dev  docker-entrypoint.d  docker-entrypoint.sh  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@nginx1:/#

 

 

  • Pod资源限制

 

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-stress2
  namespace: namespace1
spec:
  containers:
  - name: c1
    image: polinux/stress
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
    command: ["stress"]                    # 启动容器时执行的命令
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]  # 产生1个进程分配150M内存1秒后释放

 

  • Pod中多个容器网络共享

 

 

apiVersion: v1
kind: Pod
metadata:
  name: pod-share-network
spec:
  containers:
    - name: c1
      image: nginx
    - name: c2
      image: nginx
      imagePullPolicy: IfNotPresent

 

运行yaml文件

···shell

kubectl apply -f share_network.yaml

pod/pod-share-network created

kubectl get pod

2、ReplicaSet详解

如果我们都人工的去解决遇到的pod重启问题，似乎又回到了以前刀耕火种的时代了是吧，如果有一种工具能够来帮助我们管理Pod就好了，Pod不够了自动帮我新增一个，Pod挂了自动帮我在合适的节点上重新启动一个Pod，这样是不是遇到重启问题我们都不需要手动去解决了。

幸运的是，Kubernetes就为我们提供了这样的资源对象：

  • Replication Controller：用来部署、升级Pod

  • Replica Set：下一代的Replication Controller

  • Deployment：可以更加方便的管理Pod和ReplicaSet

2.1 ReplicationController

Replication Controller简称RC，RC是Kubernetes系统中的核心概念之一，简单来说，RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当Pod失败、被删除或者挂掉后，RC都会去自动创建新的Pod来保证副本数量，所以即使只有一个Pod，我们也应该使用RC来管理我们的Pod。可以说，通过ReplicationController，Kubernetes实现了集群的高可用性。

 

apiVersion: v1
kind: ReplicationController 
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

 

 

上面的YAML文件：

kind：ReplicationController

spec.replicas: 指定Pod副本数量，默认为1

spec.selector: RC通过该属性来筛选要控制的Pod

spec.template: 这里就是我们之前的Pod的定义的模块，但是不需要apiVersion和kind了

spec.template.metadata.labels: 注意这里的Pod的labels要和spec.selector相同，这样RC就可以来控制当前这个Pod了。

 

创建一个ReplicationController的横向扩展

kubectl create -f rc_nginx.yml

kubectl get pods

kubectl get rc

 

通过delete pods 的方式删除一个容器，立刻就有一个新的容器起来

kubectl get rc

kubectl get pod

kubectl delete pods nginx-h2qbt

kubectl get pods

kubectl get rc

 

scale 水平扩展的数量

kubectl scale rc nginx --replicas=2

kubectl get rc

kubectl scale rc nginx --replicas=5

kubectl get pods -o wide

 

2.2 ReplicaSet

Replication Set简称RS，随着Kubernetes的高速发展，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致，目前唯一的一个区别就是RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持基于集合的selector（version in (v1.0, v2.0)），这对复杂的运维管理就非常方便了。

kubectl命令行工具中关于RC的大部分命令同样适用于我们的RS资源对象。不过我们也很少会去单独使用RS，它主要被Deployment这个更加高层的资源对象使用，除非用户需要自定义升级功能或根本不需要升级Pod，在一般情况下，我们推荐使用Deployment而不直接使用Replica Set。

 

这里总结下关于RC/RS的一些特性和作用：

  • 大部分情况下，我们可以通过定义一个RC实现的Pod的创建和副本数量的控制

  • RC中包含一个完整的Pod定义模块（不包含apiversion和kind）

  • RC是通过label selector机制来实现对Pod副本的控制的

  • 通过改变RC里面的Pod副本数量，可以实现Pod的扩缩容功能

  • 通过改变RC里面的Pod模板中镜像版本，可以实现Pod的滚动升级功能（但是不支持一键回滚，需要用相同的方法去修改镜像地址）

 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
  labels:
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      name: nginx
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

 

#删除ReplicationController创建的pod

kubectl delete -f rc_nginx.yml

#创建一个ReplicationController的横向扩展

kubectl create -f rs_nginx.yml

kubectl get pods -o wide

kubectl get pods

kubectl get rc

 

通过delete pods 的方式删除一个容器，立刻就有一个新的容器起来

kubectl get rs

kubectl get pod

kubectl delete pods nginx-h2qbt

kubectl get pods

kubectl get rs

 

scale 水平扩展的数量

kubectl scale rs nginx --replicas=2

kubectl get rs

kubectl scale rs nginx --replicas=5

kubectl get pods -o wide

 

通过这次了解了pod的扩展，ReplicaSet和ReplicationController的方式，基本上可以抛弃上次的直接pod的方式创建app了。下次说说Deployment。

 

3、Deployment

Deployment为Pod和Replica Set提供声明式更新。

你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

注意：您不该手动管理由 Deployment 创建的 Replica Set，否则您就篡越了 Deployment controller 的职责！下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例，请直接在 Kubernetes 的代码库中提 issue。

 

Deployment可以帮我们做什么

  • 定义一组Pod期望数量，Controller会维持Pod数量与期望数量一致

  • 配置Pod的发布方式，controller会按照给定的策略更新Pod，保证更新过程中不可用 Pod维持在限定数量范围内

  • 如果发布有问题支持回滚

 

Deployment原理

控制器模型

在Kubernetes架构中，有一个叫做kube-controller-manager的组件。这个组件，是一系列控制器的集合。其中每一个控制器，都以独有的方式负责某种编排功能。而Deployment正是这些控制器中的一种。它们都遵循Kubernetes中一个通用的编排模式，即：控制循环

 

用一段go语言伪代码，描述这个控制循环

 

for {
    实际状态 := 获取集群中对象X的实际状态
    期望状态 := 获取集群中对象X的期望状态
    if 实际状态 == 期望状态 {
        什么都不做
    }else{
        执行编排动作，将实际状态调整为期望状态
    }
}

 

在具体实现中，实际状态往往来自于Kubernetes集群本身。比如Kubelet通过心跳汇报的容器状态和节点状态，或者监控系统中保存的应用监控数据，或者控制器主动收集的它感兴趣的信息，这些都是常见的实际状态的来源；期望状态一般来自用户提交的YAML文件，这些信息都保存在Etcd中

对于Deployment，它的控制器简单实现如下

  • Deployment Controller从Etcd中获取到所有携带 “app：nginx”标签的Pod，然后统计它们的数量，这就是实际状态

  • Deployment对象的replicas的值就是期望状态

  • Deployment Controller将两个状态做比较，然后根据比较结果，确定是创建Pod，还是删除已有Pod

滚动更新

Deployment滚动更新的实现，依赖的是Kubernetes中的ReplicaSet

Deployment控制器实际操纵的，就是Replicas对象，而不是Pod对象。对于Deployment、 ReplicaSet、Pod它们的关系如下图:

ReplicaSet负责通过“控制器模式”，保证系统中Pod的个数永远等于指定的个数。这也正是Deployment只允许容器的restartPolicy=Always的主要原因：只有容器能保证自己始终是running状态的前提下，ReplicaSet调整Pod的个数才有意义。

Deployment同样通过控制器模式，操作ReplicaSet的个数和属性，进而实现“水平扩展/收缩”和“滚动更新”两个编排动作对于“水平扩展/收缩”的实现，Deployment Controller只需要修改replicas的值即可。用户执行这个操作的指令如下：

 

kubectl scale deployment nginx-deployment --replicas=4

 

 

demo

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12.2
        ports:
        - containerPort: 80

 

部署

kubectl create -f deployment_nginx.yml

kubectl get deployment

kubectl get rs

kubectl get pods

 

看这个deloyment下的详情

kubectl get deployment -o wide

 

针对目前的nginx1.12升级成1.13的命令，老的下面自动移除了，全部都在新的下面。

kubectl set image deployment nginx-deployment nginx=nginx:1.13

kubectl get deployment

kubectl get deployment -o wide

kubectl get pods

 

查看历史版本

kubectl rollout history deployment nginx-deployment

回滚到之前的版本

kubectl rollout undo deployment nginx-deployment

端口暴露

kubectl get node

kubectl get node -o wide

kubectl expose deployment nginx-deployment --type=NodePort

#查看node节点暴露的端口30960

kubectl get svc

#进入minikube查看ip地址192.168.99.100

minikube ssh

 

 

容器持久化

容器网络

作用调度与资源管理

容器运行时

容器监控与日志

附录

  1. 标签

概念

Label机制是K8S中一个重要设计，通过Label进行对象弱关联，灵活地分类和选择不同服务或业务，让用户根据自己特定的组织结构以松耦合方式进行服务部署。

Label是一对KV，对用户而言非常有意义的，但对K8S本身而言没有直接意义的。Label可以在创建对象时指定，也可以在后期修改，每个对象可以拥有多个标签，但key值必须是唯一的。

Label可随意定义，但建议可读性，比如设置Pod的应用名称和版本号等。另外Lable是不具有唯一性的，为了更准确标识资源对象，应为资源对象设置多维度的label。如下：

 

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

 

 

语法和字符集

Label keys的语法

一个可选前缀+名称，通过/来区分

名称部分是必须的，并且最多63个字符，开始和结束的字符必须是字母或者数字，中间是字母数字和_、-、.。

前缀可选，如指定必须是个DNS子域，一系列的DNS label通过.来划分，长度不超过253个字符，“/”来结尾。如前缀被省略了，这个Label的key被假定为对用户私有的。系统组成部分（比如scheduler,controller-manager,apiserver,kubectl）,必须要指定一个前缀，Kuberentes.io前缀是为K8S内核部分保留的。

 

label value语法

长度不超过63个字符。

可以为空

首位字符必须为字母数字字符

中间必须是横线、_、.、数字、字母。

 

Label选择器

label选择器（selector）是K8S中核心的组织原语，通过label选择器，客户端能方便辨识和选择一组资源对象。API目前支持两种选择器：基于相等的和基于集合的。

使用基于相等的选择器时，选择器的所有键值和其他资源对象的label键值完全相同（包括数量，key和value），才能匹配。

而使用基于集合的label选择器，只要选择器部分键值匹配其他资源对象的label，就算匹配。选择器可以由一个以上条件（KV键值）组成，在多个条件的情况下，所有条件都必须满足。

 

更新资源类型的Label

Label作为用户可灵活定义的对象属性，在已创建的对象上，仍然可以随时通过kubectl label命令对其进行增加、修改、删除等操作。 例如，我们要给已创建的Pod“redis-master-bobr0”添加一个标签role=backend：

 

kubectl label pod redis-master-bobr0 role=backend
kubectl get pods -L role
    NAME           READY     STATUS    RESTARTS   AGE       ROLE
redis-master-bobr0   1/1    Running   0          3m        backend

 

删除一个Label，只需在命令行最后指定Label的key名并与一个减号相连即可：

kubectl label pod redis-master-bobr0 role-

修改一个Label的值，需要加上--overwrite参数： kubectl label pod redis-master-bobr0 role=master –overwrite

 

  1. 资源管理

概念

默认情况下，kubernetes不会限制pod等资源对象使用系统资源，单个pod或者容器可以无限制使用系统资源。

kubernetes的资源管理分为资源请求（request）和资源限制（limit），资源请求能够保证Pod有足够的资源来运行，而资源限制则是防止某个Pod无限制地使用资源，导致其他Pod崩溃。kubernetes1.5之前的版本只支持CPU和内存这两种资源类型。

三种方式

kubernetes的资源管理有3种方式，分别是单个资源对象的资源管理（以下简称resource）、limitranges、resourcequotas。resource和limitranges可以单独使用，也可以同时使用，而resourcequotas必须配合resource或者limitranges使用。limitranges和resourcequotas是针对于namespace的。

单个资源对象的资源管理

resource是针对资源对象中单个容器进行资源管理，在创建/变更资源对象时指定的。

 

kubernetes创建pod的yaml文件，参数说明

 

apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中  
kind: Pod #指定创建资源的角色/类型  
metadata: #资源的元数据/属性  
  name: web04-pod #资源的名字，在同一个namespace中必须唯一  
  labels: #设定资源的标签，详情请见http://blog.csdn.net/liyingke112/article/details/77482384
    k8s-app: apache  
    version: v1  
    kubernetes.io/cluster-service: "true"  
  annotations:            #自定义注解列表  
    - name: String        #自定义注解名字  
spec:#specification of the resource content 指定该资源的内容  
  restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器  
  nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1  
    zone: node1  
  containers:  
  - name: web04-pod #容器的名字  
    image: web:apache #容器使用的镜像地址  
    imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，
                           # Always，每次都检查
                           # Never，每次都不检查（不管本地是否有）
                           # IfNotPresent，如果本地有就不检查，如果没有就拉取
    command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT  
    args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数  
    env: #指定容器中的环境变量  
    - name: str #变量的名字  
      value: "/etc/run.sh" #变量的值  
    resources: #资源管理，请求请见http://blog.csdn.net/liyingke112/article/details/77452630
      requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行  
        cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
        memory: 32Mi #内存使用量  
      limits: #资源限制  
        cpu: 0.5  
        memory: 32Mi  
    ports:  
    - containerPort: 80 #容器开发对外的端口
      name: httpd  #名称
      protocol: TCP  
    livenessProbe: #pod内容器健康检查的设置，详情请见http://blog.csdn.net/liyingke112/article/details/77531584
      httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常  
        path: / #URI地址  
        port: 80  
        #host: 127.0.0.1 #主机地址  
        scheme: HTTP  
      initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始  
      timeoutSeconds: 5 #检测的超时时间  
      periodSeconds: 15  #检查间隔时间  
      #也可以用这种方法  
      #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常  
      #  command:  
      #    - cat  
      #    - /tmp/health  
      #也可以用这种方法  
      #tcpSocket: //通过tcpSocket检查健康   
      #  port: number   
    lifecycle: #生命周期管理  
      postStart: #容器运行之前运行的任务  
        exec:  
          command:  
            - 'sh'  
            - 'yum upgrade -y'  
      preStop:#容器关闭之前运行的任务  
        exec:  
          command: ['service httpd stop']  
    volumeMounts:  #详情请见http://blog.csdn.net/liyingke112/article/details/76577520
    - name: volume #挂载设备的名字，与volumes[*].name 需要对应    
      mountPath: /data #挂载到容器的某个路径下  
      readOnly: True  
  volumes: #定义一组挂载设备  
  - name: volume #定义一个挂载设备的名字  
    #meptyDir: {}  
    hostPath:  
      path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种

 

limitranges

LimitRange(简称limits)基于namespace的资源管理，包括pod和container的最小、最大和default、defaultrequests等。一旦创建limits，以后创建资源时，K8S将该limits资源限制条件默认&强制给pod，创建后发现不符合规则，将暂停创建pod。

概念

LimitRange(简称limits)基于namespace的资源管理，包括pod和container的最小、最大和default、defaultrequests等。

一旦创建limits，以后创建资源时，K8S将该limits资源限制条件默认/强制给pod，创建后发现不符合规则，将暂停创建pod。

在创建资源时，用户可以为pod自定义资源管理限制，在创建时会去检查和匹配limits值，发现不匹配将在创建时报错。创建后，该pod的资源使用遵守自定义规则，而不会遵守namespace的limits限制。

例子

 

kubectl delete -f lykops-limitrangerange.yaml
cat << EOF > lykops-limitrangerange.yaml
apiVersion: v1
kind: LimitRange
metadata:
  namespace: default
  name: lykops-limitrange
  labels:
    project: lykops
    app: limitrange
    version: v1
spec:
  limits:
  - max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.05
      memory: 64Mi
    type: Pod
    #注意pod只能这么多参数
  - default:
      cpu: 0.2
      memory: 200Mi
    defaultRequest:
      cpu: 0.01
      memory: 16Mi
    max:
      cpu: 0.25
      memory: 256Mi
    min:
      cpu: 0.005
      memory: 8Mi
    #container只能这么多参数
    type: Container
EOF
kubectl create -f lykops-limitrangerange.yaml

 

参数说明

每容器（type： container）

 

min：资源紧张时，最低保证可以使用的资源是： CPU 0.005个核，内存8M 
max：资源空闲时，最大可以使用的资源是：CPU 0.25个核，内存256M
default：默认时，限制使用的资源是：CPU 0.2个核，内存200M
defaultRequest：默认时，最低保证可以使用的资源是： CPU 0.01个核，内存16M

 

每pod（type： pod）

 

min：最低保证可以使用的资源是： CPU 0.05个核，内存64M 
max最大可以使用的资源是：CPU 1个核，内存1G

 

使用规则

1、每个namespace应该只有一个limits；

2、limits值设置：

 

每容器（type： container）
    max>=default>=defaultRequest>min
每pod（type： pod）
    max>=min
整个
    容器的max*容器数<=pod的max
    容器的min*容器数<=pod的min

 

3、创建资源时，pod自定义资源限制的规则：

 

自定义的单个request>=limits的容器的defaultrequets
自定义的request的总和>=limits的pod的min
自定义的单个limit<=limits的容器的requets
自定义的limit的总和<=limits的pod的max

 

使用心得

为了防止出现创建资源失败的情况，个人建议：

1、只使用limits的pod或者container中的一种，尽量不使用同时使用，特别在pod中有多容器需求的情况下。

2、尽量使用max，尽量不同时使用max和min

3、由于limits会针对该namespace下的所有新建的pods，所以在该namespace下应该运行哪些资源需求相同的业务

4、在复杂的limits配置下，不要在创建资源时使用自定义配置。

resourcequotas

Resource Quotas（资源配额，简称quota）是为了namespace进行资源配额，限制资源使用的一种策略。对于资源管理来说，quota是管理该namespace下所有资源对象的CPU、内存的limits和request的总量，如果超过该限制，资源对象无法创建。

概念

Resource Quotas（资源配额，简称quota）是对namespace进行资源配额，限制资源使用的一种策略。 K8S是一个多用户架构，当多用户或者团队共享一个K8S系统时，SA使用quota防止用户（基于namespace的）的资源抢占，定义好资源分配策略。

 

Quota应用在Namespace上，默认情况下，没有Resource Quota的，需要另外创建Quota，并且每个Namespace最多只能有一个Quota对象。

限额资源类型

 

计算资源：limits.cpu、requests.cpu、limits.memory、requests.memory
存储资源，包括存储资源的总量以及指定storage class的总量
    requests.storage：存储资源总量，如500Gi
    persistentvolumeclaims：pvc的个数
    .storageclass.storage.k8s.io/requests.storage
    .storageclass.storage.k8s.io/persistentvolumeclaims
对象数，即可创建的对象的个数
    pods,replicationcontrollers,configmaps,secrets，persistentvolumeclaims，services,services.loadbalancers,services.nodeports

 

使用注意实现

 

在使用前需确认apiserver的配置文件中的KUBE_ADMISSION_CONTROL是否有ResourceQuota，如果没有需要添加并重启apiserver。
Quota依赖于资源管理器，可以使用资源对象limits或者在创建资源对象是为pod设置资源限制（resources），如果不设置，资源对象无法创建。
当该namespace中的任意个额度达到预设Quota时，将无法创建资源对象。

 

例子

比如K8S系统共有20核CPU和32GB内存，分配给lykops用户5核CPU和16GB，分配给lykchat租户5核CPU 和8GB，预留10核CPU和8GB内存。这样，用户中所使用的CPU和内存的总和不能超过指定的资源配额，促使其更合理地使用资源。

 

kubectl delete -f resourcequota.yaml
cat << EOF > resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  namespace: lykops
  name: lykops
  labels:
    project: lykops
    app: resourcequota
    version: v1
spec:
  hard:
    pods: 50
    requests.cpu: 0.5
    requests.memory: 512Mi
    limits.cpu: 5
    limits.memory: 16Gi
    configmaps: 20
    persistentvolumeclaims: 20
    replicationcontrollers: 20
    secrets: 20
    services: 50
EOF
kubectl create -f resourcequota.yaml

 

 

 

配置规则

1、每个namespace有且只有一个limits和quota

2、limits的同种类型（CPU或者memory）配置规则：

每容器（type： container）：max>=default>=defaultRequest>min

每pod（type： pod）：max>=min

pod和容器对应关系：容器max*容器数<=pod max；容器min*容器数<=pod min

3、在同一个namespace下，limits和单个资源对象的资源管理（resource）同时使用，同种类型（CPU或者memory）配置规则：resource的单个资源配置范围不能超过limit的容器范围，总和不能超过limit的pod范围。

具体如下：

resource的request的总和（如有多个容器，所有的）>= limits的容器的defaultrequets*容器数 >= limits的pod的min

resource的limit的总和（如有多个容器，所有的）<= limits的容器的requets*容器数 <= limits的pod的max

配置正确，kubernetes将按照resource进行资源管理，如果配置错误，无法创建对象。

4、quota需要配合limits或者resource，如果没有配置limits时，每次创建对象时，必须配置resource，否则无法创建对象

5、该namespace下，所有pod/容器的CPU或者memory的limit、request的任意一种总量大于quota相对应的值后，无法分配更多的系统资源，无法创建新的资源对象，无法扩容RC、RS等。

使用心得

1、资源管理对象单一性

尽量使用limits针对容器（更好）或者pod的资源管理，尽量不同时针对容器和pod，在一pod多容器情况下，即使有充足系统资源，创建资源对象失败几率高。

在limits使用的namespace下，最好不要在创建资源时使用resource。

2、资源管理类型单一性

使用资源限制（limit或者max）或者资源请求（request或者min）

同时使用时，最好保持“1、资源管理对象单一性”

3、服务部署单一性

由于limits会针对该namespace下的所有pod或者容器，所以在该namespace下尽量部署资源需求相同的服务

4、合理配置

  1. 应用程序健康检查

K8S的应用程序健康检查分为livenessProbe和readinessProbe，两者相似，但两者存在着一些区别。

livenessProbe在服务运行过程中检查应用程序是否运行正常，不正常将杀掉进程；而readness Probe是用于检测应用程序启动完成后是否准备好对外提供服务，不正常继续检测，直到返回成功为止。

livenessProbe

许多应用程序经过长时间运行，最终过渡到无法运行的状态，除了重启，无法恢复。通常情况下，K8S会发现应用程序已经终止，然后重启应用程序/pod。

有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致K8S无法隔离有故障的pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S提供livenessProbe来检测应用程序是否正常运行，并且对相应状况进行相应的补救措施。

readinessProbe

在没有配置readinessProbe的资源对象中，pod中的容器启动完成后，就认为pod中的应用程序可以对外提供服务，该pod就会加入相对应的service，对外提供服务。但有时一些应用程序启动后，需要较长时间的加载才能对外服务，如果这时对外提供服务，执行结果必然无法达到预期效果，影响用于体验。

比如使用tomcat的应用程序来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接没连上等等。对于spring boot应用，默认的actuator带有/health接口，可以用来进行启动成功的判断。

检测方式

exec-命令

在用户容器内执行一次命令，如果命令执行的退出码为0，则认为应用程序正常运行，其他任务应用程序运行不正常。

 

……
  livenessProbe:
    exec:
      command:
      - cat
      - /home/laizy/test/hostpath/healthy
……

 

TCPSocket

将会尝试打开一个用户容器的Socket连接（就是IP地址：端口）。如果能够建立这条连接，则认为应用程序正常运行，否则认为应用程序运行不正常。

 

……      
livenessProbe:
tcpSocket:
   port: 8080
……

 

HTTPGet 调用容器内Web应用的web hook，如果返回的HTTP状态码在200和399之间，则认为应用程序正常运行，否则认为应用程序运行不正常。每进行一次HTTP健康检查都会访问一次指定的URL。

 

……
  httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常
    path: / #URI地址
    port: 80 #端口号
    #host: 127.0.0.1 #主机地址
    scheme: HTTP #支持的协议，http或者https
  httpHeaders：’’ #自定义请求的header
……

 

部署例子

 

cat << EOF > inessprobe.yaml
apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: inessprobe
  labels: 
    project: lykops
    app: inessprobe
    version: v1  
spec:
  replicas: 6
  selector: 
    project: lykops
    app: inessprobe
    version: v1
    name: inessprobe
  template: 
    metadata:
      labels: 
        project: lykops
        app: inessprobe
        version: v1
        name: inessprobe
    spec:
      restartPolicy: Always 
      containers:
      - name: inessprobe
        image: web:apache 
        imagePullPolicy: Never 
        command: ['sh',"/etc/run.sh" ] 
        ports:
        - containerPort: 80
          name: httpd
          protocol: TCP
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 120 
          periodSeconds: 15 
          timeoutSeconds: 5
        livenessProbe: 
          httpGet: 
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 180 
          timeoutSeconds: 5 
          periodSeconds: 15 
EOF
 
cat << EOF > inessprobe-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: inessprobe
  labels:
    project: lykops
    app: inessprobe
    version: v1
spec:
  selector:
    project: lykops
    app: inessprobe
    version: v1
  ports:
  - name: http
    port: 80
    protocol: TCP
EOF
 
kubectl create -f inessprobe-svc.yaml
kubectl create -f inessprobe.yaml

 

参数说明

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。

periodSeconds：执行探测的频率。默认是10秒，最小1秒。

timeoutSeconds：探测超时时间。默认1秒，最小1秒。

successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。

failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是3。最小值是1。

 

  1. Volume

在Docker的设计实现中，容器中的数据是临时的，即当容器被销毁时，其中的数据将会丢失。如果需要持久化数据，需要使用Docker数据卷挂载宿主机上的文件或者目录到容器中。在K8S中，当Pod重建的时候，数据是会丢失的，K8S也是通过数据卷挂载来提供Pod数据的持久化的。K8S数据卷是对Docker数据卷的扩展，K8S数据卷是Pod级别的，可以用来实现Pod中容器的文件共享。

支持的类型

EmptyDir

HostPath

GCE PersistentDisk

AWS ElasticBlock Store

NFS

iSCSI

Flocker

GlusterFS

RBD

Git Repo

Secret

PersistentVolume Claim

Downward API

本地数据卷

EmptyDir、HostPath这两种类型的数据卷，只能用于本地文件系统。本地数据卷中的数据只会存在于一台机器上，所以当Pod发生迁移的时候，数据便会丢失。该类型Volume的用途是：Pod中容器间的文件共享、共享宿主机的文件系统。

EmptyDir

如果Pod配置了EmpyDir数据卷，在Pod的生命周期内都会存在，当Pod被分配到Node上时，会在Node上创建EmptyDir数据卷，并挂载到Pod的容器中。只要Pod存在，EmpyDir数据卷都会存在（容器删除不会导致EmpyDir数据卷丟失数据），但是如果Pod的生命周期终结（Pod被删除），EmpyDir数据卷也会被删除，并且永久丢失。

EmpyDir数据卷非常适合实现Pod中容器的文件共享。Pod的设计提供了一个很好的容器组合的模型，容器之间各司其职，通过共享文件目录来完成交互，比如可以通过一个专职日志收集容器，在每个Pod中和业务容器中进行组合，来完成日志的收集和汇总。

HostPath

HostPath数据卷允许将容器宿主机上的文件系统挂载到Pod中。如果Pod需要使用宿主机上的某些文件，可以使用HostPath。

网络数据卷

K8S提供了很多类型的数据卷以集成第三方的存储系统，包括一些非常流行的分布式文件系统，也有在IaaS平台上提供的存储支持，这些存储系统都是分布式的，通过网络共享文件系统，因此我们称这一类数据卷为网络数据卷。

网络数据卷能够满足数据的持久化需求，Pod通过配置使用网络数据卷，每次Pod创建的时候都会将存储系统的远端文件目录挂载到容器中，数据卷中的数据将被永久保存，即使Pod被删除，只是除去挂载数据卷，数据卷中的数据仍然保存在存储系统中，且当新的Pod被创建时，仍是挂载同样的数据卷。网络数据卷包含以下几种：NFS、iSCISI、GlusterFS、RBD（Ceph Block Device）、Flocker、AWS Elastic Block Store、GCE Persistent Disk

信息数据卷

K8S中有一些数据卷，主要用来给容器传递配置信息，称之为信息数据卷，比如Secret（处理敏感配置信息，密码、Token等）、Downward API（通过环境变量的方式告诉容器Pod的信息）、Git Repo（将Git仓库下载到Pod中），都是将Pod的信息以文件形式保存，然后以数据卷方式挂载到容器中，容器通过读取文件获取相应的信息。

 

  1. k8s认证&授权

认证

 

授权

  1. 其他学习地址

https://k8s.easydoc.net/docs/dRiQjyTY/28366845/6GiNOzyZ/3iQiyInr

https://console.cloud.tencent.com/tke2/cluster?rid=19

 

 

 

 

标签：容器,name,kubectl,手册,学习,nginx,Pod,k8s,pod
From： https://www.cnblogs.com/chengleijiang/p/16934399.html

相关文章

  • 学习笔记|因子的评价体系和有效性评价方式IC与IR
    来源  https://xueqiu.com/6223446183/202373376  学习笔记|因子的评价体系和有效性评价方式IC与IR因子评价维度因子单调性：因子单调性越高，收益越强。因子有效性......
  • k8s实战入门
    实战入门本章节将介绍如何在kubernetes集群中部署一个nginx服务，并且能够对其进行访问。NamespaceNamespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实......
  • HCIA学习笔记四十三：NAT网络地址转换
    一、NAT应用场景• 企业或家庭所使用的网络为私有网络，使用的是私有地址；运营商维护的网络为公共网络，使用的是公有地址。私有地址不能在公网中路由。• NAT一般部署在连......
  • MaekDown学习
    MarkDown学习标签二级标题三级标题四级标题。。。。 字体hello，word！hello，word！hello，word！hello，word！ 引用再小的船也能扬帆远航 分割线 图片 超......
  • 【GIS开发】OpenLayers入门学习（JavaScript库）
    文章目录​​1、简介​​​​2、快速入门​​​​2.1在线库快速入门​​​​2.2本地库快速入门​​​​2.3nodejs快速入门​​​​2.4vue快速入门​​​​2.5python快......
  • MySQL学习笔记
    MySQL学习笔记终端操作mysql数据库1>mysql-uroot-proot2>查看有哪些数据库showdatabases;±-------------------+|Database|±-------------------+|information_......
  • C++学习------cmath头文件的源码学习06
    函数族定义---双曲函数cosh---计算双曲余弦函数sinh---计算双曲正弦函数tanh---计算双曲正切函数acosh---计算双曲余弦面积asinh---计算双曲正弦面积atanh---计算双曲正切面......
  • 大数据学习之HDFS
    HDFS是一个分布式文件存储系统，适合一次写入，多次写出，且不支持文件修改  结构：    NameNode(NN):就是master他是一个管理者      1、管理HDFS的......
  • 大数据学习之Hadoop
    Hadoop是一个支持海量数据的分布式存储和分布式计算的平台  包含:    HDFS    YARN    MapReduce  分布式管理系统（HDFS）   ......
  • Java学习八
    一.小结1.类是对象的模板。它定义对象的属性，并提供创建对象的构造方法以及对对象进行操作的方法。2.类也是一种数据类型。可以用它声明对象引用变量。对象引用变量中似乎......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99