文章系列

回顾

容器，其实是一种特殊的进程而已。

现在，你应该可以理解，对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：

启用 Linux Namespace 配置；
设置指定的 Cgroups 参数；
切换进程的根目录（Change Root）

Kubernetes 是云原生时代的操作系统

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VvcAdTEl-1650714444487)(https://cdn.jsdelivr.net/gh/Fly0905/note-picture@main/img/202204230918650.png)]

Kubernetes Pod详解

Kubernets概览

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W9556ihZ-1650714444489)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

Kubernetes关键概念-Pod

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-otGzBBdt-1650714444490)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

1. Pod详解-容器

使用 Init 容器

因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问应用容器不能访问的 Secret 的权限。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

Init 容器示例

下面是一些如何使用 Init 容器的想法：

等待一个 Service 完成创建，通过类似如下 shell 命令：

for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1

注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下：

curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register \
  -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'

在启动应用容器之前等一段时间，使用类似命令：
```
sleep 60
```
克隆 Git 仓库到卷中。
将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。

容器基本组成

2. Pod详解-资源需求和QoS

资源请求和限制的原理

以下面定义的cpu-mem-request-limit.yaml为例，研究下pod中定义的requests和limits应用在docker生效的参数：

apiVersion: v1
kind: Pod
metadata:
  name: cpu-mem-request-limit
  namespace: fly-test
  labels:
    name: cpu-mem-request-limit
spec:
  containers:
    - name: cpu-mem-request-limit
      image: nginx:1.7.9
      imagePullPolicy: IfNotPresent
      ports:
        - name: nginx-port-80
          protocol: TCP
          containerPort: 80
      resources:
        requests:
          cpu: 0.25
          memory: 128Mi
        limits:
          cpu: 500m
          memory: 256Mi

1、获取容器的id号，可以通过kubectl describe pods cpu-mem-request-limit的containerID获取到容器的id，或者登陆到node-3节点通过名称过滤获取到容器的id号，默认会有两个pod：一个通过pause镜像创建，另外一个通过应用镜像创建

[root@gv41New95 2-pod-resource]# docker container list | grep cpu-mem-request-limit
d9b2a8b67fea   84581e99d807                                        "nginx -g 'daemon of…"   About a minute ago   Up 59 seconds             k8s_cpu-mem-request-limit_cpu-mem-request-limit_fly-test_3cd9ea76-259b-4b64-98f2-ff61c8965cb5_0
ec09131f6e05   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                 About a minute ago   Up 59 seconds             k8s_POD_cpu-mem-request-limit_fly-test_3cd9ea76-259b-4b64-98f2-ff61c8965cb5_0

2、查看docker容器详情信息

[root@node-3 ~]# docker container inspect d9b2a8b67fea
[
    {
        "Image": "sha256:84581e99d807a703c9c03bd1a31cd9621815155ac72a7365fd02311264512656",
        "ResolvConfPath": "/var/lib/docker/containers/2fe0498ea9b5dfe1eb63eba09b1598a8dfd60ef046562525da4dcf7903a25250/resolv.conf",
        "HostConfig": {
            "Binds": [
                "/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/volumes/kubernetes.io~secret/default-token-5qwmc:/var/run/secrets/kubernetes.io/serviceaccount:ro",
                "/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/etc-hosts:/etc/hosts",
                "/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/containers/ cpu-mem-request-limit/1cc072ca:/dev/termination-log"
            ],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {
                    "max-size": "100m"
                }
            },
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 256,        CPU分配的权重，作用在requests.cpu上
            "Memory": 268435456,     内存分配的大小，作用在limits.memory上
            "NanoCpus": 0,
            "CgroupParent": "kubepods-burstable-pod66958ef7_507a_41cd_a688_7a4976c6a71e.slice",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 100000,    CPU分配的使用比例，和CpuQuota一起作用在limits.cpu上
            "CpuQuota": 50000,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": [],
            "DeviceCgroupRules": null,
            "DiskQuota": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 268435456,
            "MemorySwappiness": null,
            "OomKillDisable": false,
            "PidsLimit": 0,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
        },   
    }
]

CPU和内存请求和限制的目的

通过为集群中运行的容器配置CPU和内存请求和限制，你可以有效利用集群节点上可用的CPU和内存资源。通过将 Pod 的CPU和内存请求保持在较低水平，你可以更好地安排 Pod 调度。通过让CPU和内存限制大于CPU和内存请求，你可以完成两件事：

Pod 可以进行一些突发活动，从而更好的利用可用CPU和内存。
Pod 在突发活动期间，可使用的CPU和内存被限制为合理的数量。

如果你没有指定CPU和内存限制

如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：

容器可无限制地使用CPU和内存。容器可以使用其所在节点所有的可用CPU和内存，进而可能导致该节点调用 OOM Killer。此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。
运行的容器所在命名空间有默认的CPU和内存限制，那么该容器会被自动分配默认限制。集群管理员可用使用 LimitRange 来指定默认的内存限制。

如果你设置了 CPU 限制和内存但未设置 CPU 请求和内存

如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其设置与 CPU 限制相同的 CPU 请求值。

类似的，如果容器设置了内存限制值但未设置内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。

QoS

QoS 类为 Guaranteed的 Pod

Pod 中的每个容器都必须指定内存限制和内存请求。
对于 Pod 中的每个容器，内存限制必须等于内存请求。
Pod 中的每个容器都必须指定 CPU 限制和 CPU 请求。
对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。

  limits:
    memory: "200Mi"
    cpu: "700m"
  requests:
    memory: "200Mi"
    cpu: "700m"

QoS 类为 Burstable 的 Pod

Pod 不符合 Guaranteed QoS 类的标准。
Pod 中至少一个容器具有内存或 CPU 请求。

resources:
  limits:
    memory: "200Mi"
  requests:
    memory: "100Mi"

QoS 类为 BestEffort 的 Pod

没有设置内存和 CPU 限制或请求

不同的 QoS 表现

不同的 Qos 在调度和底层表现有什么样的不同？

不同的 Qos，它其实在调度和底层表现上都有一些不一样。比如说调度表现， 调度器只会使用 request 进行调度，也就是不管你配了多大的 limit，它都不会进行调度使用，它只会使用 request 进行调度。

在底层上，不同的 Qos 表现更不相同。比如说 CPU，它其实是按 request 来划分权重的，不同的 Qos，它的 request 是完全不一样的，比如说像 Burstable 和 BestEffort，它可能 request 可以填很小的数字或者不填，这样的话，它的权重其实是非常低的。像 BestEffort，它的权重可能是只有 2，而 Burstable 或 Guaranteed，它的权重可以多到几千。

另外，当我们开启了 kubelet 的一个特性，叫 cpu-manager-policy=static 的时候，我们 Guaranteed Qos，如果它的 request 是一个整数的话，比如说配了 2，它会对 Guaranteed Pod 进行绑核。也就是具体像下面这个例子，它分配 CPU0 和 CPU1 给 Guaranteed Pod。

QoS 应用场景之一：Eviction

Kubernetes 为 Pod 设置这样三种 QoS 类别，具体有什么作用呢？

实际上，QoS 划分的主要应用场景，是当宿主机资源紧张的时候，kubelet 对 Pod 进行 Eviction（即资源回收）时需要用到的。

具体地说，当 Kubernetes 所管理的宿主机上不可压缩资源短缺时，就有可能触发 Eviction。比如，可用内存（memory.available）、可用的宿主机磁盘空间（nodefs.available），以及容器运行时镜像存储空间（imagefs.available）等等。

目前，Kubernetes 为你设置的 Eviction 的默认阈值如下所示：

memory.available<100Mi
nodefs.available<10%
nodefs.inodesFree<5%
imagefs.available<15%

当然，上述各个触发条件在 kubelet 里都是可配置的。比如下面这个例子：

kubelet --eviction-hard=imagefs.available<10%,
memory.available<500Mi,
nodefs.available<5%,
nodefs.inodesFree<5% 
--eviction-soft=imagefs.available<30%,nodefs.available<10% 
--eviction-soft-grace-period=imagefs.available=2m,nodefs.available=2m 
--eviction-max-pod-grace-period=600

在这个配置中，你可以看到Eviction 在 Kubernetes 里其实分为 Soft 和 Hard 两种模式。

其中，Soft Eviction 允许你为 Eviction 过程设置一段“优雅时间”，比如上面例子里的 imagefs.available=2m，就意味着当 imagefs 不足的阈值达到 2 分钟之后，kubelet 才会开始 Eviction 的过程。

而 Hard Eviction 模式下，Eviction 过程就会在阈值达到之后立刻开始。

Kubernetes 计算 Eviction 阈值的数据来源，主要依赖于从 Cgroups 读取到的值，以及使用 cAdvisor 监控到的数据。

当宿主机的 Eviction 阈值达到后，就会进入 MemoryPressure 或者 DiskPressure 状态，从而避免新的 Pod 被调度到这台宿主机上。

而当 Eviction 发生的时候，kubelet 具体会挑选哪些 Pod 进行删除操作，就需要参考这些 Pod 的 QoS 类别了。

当然，对于同 QoS 类别的 Pod 来说，Kubernetes 还会根据 Pod 的优先级来进行进一步地排序和选择。

资源配额的工作方式：

不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。
集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），并在消息中给出有可能违反的约束。
如果命名空间下的计算资源（如 cpu 和 memory）的配额被启用，则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

如何满足 Pod 资源要求？

上面介绍完了基础资源的使用方式，也就是我们做到了如何满足 Pod 资源要求。下面做一个小结：

Pod 要配置合理的资源要求
- CPU/Memory/EphemeralStorage/GPU
通过 Request 和 Limit 来为不同业务特点的 Pod 选择不同的 QoS
- Guaranteed：敏感型，需要业务保障；
- Burstable：次敏感型，需要弹性业务
- BestEffort：可容忍性业务（尽力而为）

资源请求和限制的生产建议

requests和limits资源定义推荐不超过1:2，避免分配过多资源而出现资源争抢，发生OOM；
pod中默认没有定义resource，推荐给namespace定义一个limitrange，确保pod能分到资源；
防止node上资源过度而出现机器hang住或者OOM，建议node上设置保留和驱逐资源，如保留资源–system-reserved=cpu=200m,memory=1G，驱逐条件–eviction hard=memory.available<500Mi。

3. Pod详解-健康检查

三种探针Probe

应用在运行过程中难免会出现错误，如程序异常，软件异常，硬件故障，网络故障等，kubernetes提供Health Check健康检查机制，当发现应用异常时会自动重启容器，将应用从service服务中剔除，保障应用的高可用性。k8s定义了三种探针Probe：

liveness probes 在线检查机制，检查应用是否可用，如死锁，无法响应，异常时会自动重启容器; 用于存活检查，检查容器内部运行状态
readiness probes 准备就绪检查，通过readiness是否准备接受流量，准备完毕加入到endpoint，否则剔除; 用于健康检查和服务探测机制
startup probes 启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被前面的探针kill掉

三种健康检查方法

每种探测机制支持三种健康检查方法，分别是命令行exec，httpGet和tcpSocket，其中exec通用性最强，适用与大部分场景，tcpSocket适用于TCP业务，httpGet适用于web业务。

exec 提供命令或shell的检测，在容器中执行命令检查，返回码为0健康，非0异常
httpGet http协议探测，在容器中发送http请求，根据http返回码判断业务健康情况
tcpSocket tcp协议探测，向容器发送tcp建立连接，能建立则说明正常

配置探测器

Probe 有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为：

initialDelaySeconds：容器启动后要等待多少秒后才启动存活和就绪探测器，默认是 0 秒，最小值是 0。
periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活和启动探测的这个值必须是 1。最小值是 1。
failureThreshold：当探测失败时，Kubernetes 的重试次数。对存活探测而言，放弃就意味着重新启动容器。对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

4. Pod详解-配置文件

配置文件（ ConfigMap）及密钥（ Secret）介绍

5. Pod详解-持久化存储

volume存储

kubernetes容器中的数据是临时的，即当重启重启或crash后容器的数据将会丢失，此外容器之间有共享存储的需求，所以kubernetes中提供了volume存储的抽象，volume后端能够支持多种不同的plugin驱动，通过.spec.volumes中定义一个存储，然后在容器中.spec.containers.volumeMounts调用，最终在容器内部以目录的形式呈现。

kubernetes内置能支持多种不同的驱动类型，大体上可以分为四种类型：

1. 公/私有云驱动接口

类型	说明
awsElasticBlockStore	AWS的EBS云盘
azureFile	微软NAS存储
gcePersistentDisk	google云盘
cinder	openstack cinder云盘
vsphereVolume	VMware的VMFS存储
scaleIO	EMC分布式存储

2. 开源存储驱动接口

类型	说明
ceph rbd	ceph块存储
cephfs	glusterfs存储
nfs	nfs文件
flexvolume	社区标准化驱动
csi	社区标准化驱动

3. 本地临时存储

类型	说明
hostpath	宿主机文件
emptyDir	临时目录

4. kubernetes对象API驱动接口

类型	说明
configMap	调用configmap对象，注入配置文件
secrets	调用secrets对象，注入秘文配置文件
persistentVolumeClaim	通过pvc调用存储
downloadAPI
projected

PV，PVC和StorageClass

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Hh7r1GPj-1650714444497)(https://cdn.jsdelivr.net/gh/Fly0905/note-picture@main/img/202204222056762.png)]

pv, pvc和storageclass关系

请添加图片描述 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vUHepFxx-1650714444499)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

从图中我们可以看到，在这个体系中：

当然，StorageClass 的另一个重要作用，是指定 PV 的 Provisioner（存储插件）。这时候，如果你的存储插件支持 Dynamic Provisioning 的话，Kubernetes 就可以自动为你创建 PV 了。

Kubernetes 为我们提供了一套可以自动创建 PV 的机制，即：Dynamic Provisioning。相比之下，人工管理 PV 的方式就叫作 Static Provisioning。Dynamic Provisioning 机制工作的核心，在于一个名叫 StorageClass 的 API 对象。

简而言之：

StorageClass (SC)：存储类，类似存储池的概念，包括了存储池的一些信息；

PersistenVolume (PV)：持久卷，独立的存储资源对象，其生命周期与Pod无关；

PersistenVolumeClaim (PVC): 声明，代表计算任务对存储资源的需求。

这种存储结构是为了解决

有状态的容器实例需要持久化卷；
容器实例动态提供新卷；
不同类型的应用需要不同访问模式的存储卷；
解耦计算资源和存储资源。

6. Pod详解-服务域名发现

如何快速编写yaml文件

通过定义模版快速生成

通过定义模版快速生成，kubectl create apps -o yaml --dry-run的方式生成，–dry-run仅仅是试运行，并不实际在k8s集群中运行，通过指定-o yaml输出yaml格式文件，生成后给基于模版修改即可，如下：

[root@node-1 demo]# kubectl create deployment demo --image=nginx:latest  --dry-run -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: demo
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: demo
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        resources: {}
status: {}

explain命令

explain命令堪称是语法查询器，可以查到每个字段的含义，使用说明和使用方式，如想要查看Pod的spec中containers其他支持的字段，可以通过kubectl explain Pod.spec.containers的方式查询，如下：

[root@node-1 demo]# kubectl explain Pods.spec.containers
KIND:     Pod
VERSION:  v1

RESOURCE: containers <[]Object>

DESCRIPTION:
     List of containers belonging to the pod. Containers cannot currently be
     added or removed. There must be at least one container in a Pod. Cannot be
     updated.

     A single application container that you want to run within a pod.

FIELDS:
   args	<[]string> #命令参数
     Arguments to the entrypoint. The docker image's CMD is used if this is not
     provided. Variable references $(VAR_NAME) are expanded using the
     container's environment. If a variable cannot be resolved, the reference in
     the input string will be unchanged. The $(VAR_NAME) syntax can be escaped
     with a double $$, ie: $$(VAR_NAME). Escaped references will never be
     expanded, regardless of whether the variable exists or not. Cannot be
     updated. More info:
     https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

   image	<string> #镜像定义
     Docker image name. More info:
     https://kubernetes.io/docs/concepts/containers/images This field is
     optional to allow higher level config management to default or override
     container images in workload controllers like Deployments and StatefulSets.

   ports	<[]Object> #端口定义
     List of ports to expose from the container. Exposing a port here gives the
     system additional information about the network connections a container
     uses, but is primarily informational. Not specifying a port here DOES NOT
     prevent that port from being exposed. Any port which is listening on the
     default "0.0.0.0" address inside a container will be accessible from the
     network. Cannot be updated.

   readinessProbe	<Object> #可用健康检查
     Periodic probe of container service readiness. Container will be removed
     from service endpoints if the probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

   resources	<Object> #资源设置
     Compute Resources required by this container. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

...省略部分输出...
   volumeMounts	<[]Object> #挂载存储
     Pod volumes to mount into the container's filesystem. Cannot be updated.

   workingDir	<string>
     Container's working directory. If not specified, the container runtime's
     default will be used, which might be configured in the container image.
     Cannot be updated.

关于explain内容解释说明

<string> 表示后面接一个字符串
<[]Object> 表示后面是一个列表的对象，列表需要以-开始，且可以写多个
<Object> 表示一个对象，对象内部包含多个属性

Kubectl接口调试

[root@10 ~]# kubectl get pod --v=0
NAME                                       READY   STATUS                  RESTARTS   AGE
api-demo-56db594ddf-rc5jf                  1/1     Running                 1          29d
busybox                                    1/1     Running                 0          22h
busybox-6f88f747db-c5pdn                   0/1     CrashLoopBackOff        3597       21d
busybox-deployment-7d8b8f459f-5c26l        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-6m27f        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-7xq5q        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-ck4ff        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-gq5fs        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-vfxvc        1/1     Running                 0          21h
ds.kusc00201-5b6hn                         1/1     Running                 1          20d
ds.kusc00201-9jqmt                         1/1     Running                 0          20d
ds.kusc00201-bf6tx                         1/1     Running                 0          20d
ds.kusc00201-c8rxh                         1/1     Running                 0          20d
ds.kusc00201-cgjzz                         1/1     Running                 1          20d
ds.kusc00201-gpstf                         1/1     Running                 0          20d
ds.kusc00201-js47m                         1/1     Running                 0          20d
falco-daemonset-2hg9w                      1/1     Running                 0          32h
falco-daemonset-68sc9                      1/1     Running                 1          32h
falco-daemonset-944zb                      1/1     Running                 1          32h
falco-daemonset-d8dnh                      1/1     Running                 0          32h
falco-daemonset-db7vg                      1/1     Running                 1          32h
falco-daemonset-kr8wj                      1/1     Running                 0          32h
falco-daemonset-vdsb6                      1/1     Running                 2          32h
lumpy--koala                               0/1     Init:CrashLoopBackOff   3695       20d
nginx-864459b57d-zqgjt                     1/1     Running                 0          21h
single-nginx-deployment-69dd5c845f-5znk9   1/1     Running                 0          44d
single-nginx-deployment-69dd5c845f-85vvr   0/1     ContainerCreating       0          21h
single-nginx-deployment-69dd5c845f-cdkfc   1/1     Running                 0          21d
test                                       1/1     Running                 1          19d
[root@10 ~]# kubectl get pod --v=2
I0108 19:16:05.058744  409257 get.go:558] no kind is registered for the type v1beta1.Table in scheme "k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:29"
NAME                                       READY   STATUS                  RESTARTS   AGE
api-demo-56db594ddf-rc5jf                  1/1     Running                 1          29d
busybox                                    1/1     Running                 0          22h
busybox-6f88f747db-c5pdn                   0/1     CrashLoopBackOff        3597       21d
busybox-deployment-7d8b8f459f-5c26l        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-6m27f        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-7xq5q        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-ck4ff        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-gq5fs        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-vfxvc        1/1     Running                 0          21h
ds.kusc00201-5b6hn                         1/1     Running                 1          20d
ds.kusc00201-9jqmt                         1/1     Running                 0          20d
ds.kusc00201-bf6tx                         1/1     Running                 0          20d
ds.kusc00201-c8rxh                         1/1     Running                 0          20d
ds.kusc00201-cgjzz                         1/1     Running                 1          20d
ds.kusc00201-gpstf                         1/1     Running                 0          20d
ds.kusc00201-js47m                         1/1     Running                 0          20d
falco-daemonset-2hg9w                      1/1     Running                 0          32h
falco-daemonset-68sc9                      1/1     Running                 1          32h
falco-daemonset-944zb                      1/1     Running                 1          32h
falco-daemonset-d8dnh                      1/1     Running                 0          32h
falco-daemonset-db7vg                      1/1     Running                 1          32h
falco-daemonset-kr8wj                      1/1     Running                 0          32h
falco-daemonset-vdsb6                      1/1     Running                 2          32h
lumpy--koala                               0/1     Init:CrashLoopBackOff   3695       20d
nginx-864459b57d-zqgjt                     1/1     Running                 0          21h
single-nginx-deployment-69dd5c845f-5znk9   1/1     Running                 0          44d
single-nginx-deployment-69dd5c845f-85vvr   0/1     ContainerCreating       0          21h
single-nginx-deployment-69dd5c845f-cdkfc   1/1     Running                 0          21d
test                                       1/1     Running                 1          19d
[root@10 ~]# kubectl get pod --v=8
I0108 19:16:08.907946  409391 loader.go:359] Config loaded from file /root/.kube/config
I0108 19:16:08.912806  409391 loader.go:359] Config loaded from file /root/.kube/config
I0108 19:16:08.924331  409391 loader.go:359] Config loaded from file /root/.kube/config
I0108 19:16:08.947717  409391 loader.go:359] Config loaded from file /root/.kube/config
I0108 19:16:08.948706  409391 round_trippers.go:383] GET https://10.10.101.170:6443/api/v1/namespaces/default/pods?limit=500
I0108 19:16:08.948739  409391 round_trippers.go:390] Request Headers:
I0108 19:16:08.948755  409391 round_trippers.go:393]     Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json
I0108 19:16:08.948771  409391 round_trippers.go:393]     User-Agent: kubectl/v1.12.3 (linux/amd64) kubernetes/435f92c
I0108 19:16:08.989401  409391 round_trippers.go:408] Response Status: 200 OK in 40 milliseconds
I0108 19:16:08.989454  409391 round_trippers.go:411] Response Headers:
I0108 19:16:08.989471  409391 round_trippers.go:414]     Content-Type: application/json
I0108 19:16:08.989485  409391 round_trippers.go:414]     Date: Wed, 08 Jan 2020 11:16:08 GMT
I0108 19:16:08.990879  409391 request.go:942] Response Body: {"kind":"Table","apiVersion":"meta.k8s.io/v1beta1","metadata":{"selfLink":"/api/v1/namespaces/default/pods","resourceVersion":"53664878"},"columnDefinitions":[{"name":"Name","type":"string","format":"name","description":"Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names","priority":0},{"name":"Ready","type":"string","format":"","description":"The aggregate readiness state of this pod for accepting traffic.","priority":0},{"name":"Status","type":"string","format":"","description":"The aggregate status of the containers in this pod.","priority":0},{"name":"Restarts","type":"integer","format":"","description":"The number of times the containers in this pod have been restarted.","priority":0},{"name":"Age","type":"str [truncated 24720 chars]
I0108 19:16:09.005556  409391 get.go:558] no kind is registered for the type v1beta1.Table in scheme "k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:29"
NAME                                       READY   STATUS                  RESTARTS   AGE
api-demo-56db594ddf-rc5jf                  1/1     Running                 1          29d
busybox                                    1/1     Running                 0          22h
busybox-6f88f747db-c5pdn                   0/1     CrashLoopBackOff        3597       21d
busybox-deployment-7d8b8f459f-5c26l        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-6m27f        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-7xq5q        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-ck4ff        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-gq5fs        1/1     Running                 0          21h
busybox-deployment-7d8b8f459f-vfxvc        1/1     Running                 0          21h
ds.kusc00201-5b6hn                         1/1     Running                 1          20d
ds.kusc00201-9jqmt                         1/1     Running                 0          20d
ds.kusc00201-bf6tx                         1/1     Running                 0          20d
ds.kusc00201-c8rxh                         1/1     Running                 0          20d
ds.kusc00201-cgjzz                         1/1     Running                 1          20d
ds.kusc00201-gpstf                         1/1     Running                 0          20d
ds.kusc00201-js47m                         1/1     Running                 0          20d
falco-daemonset-2hg9w                      1/1     Running                 0          32h
falco-daemonset-68sc9                      1/1     Running                 1          32h
falco-daemonset-944zb                      1/1     Running                 1          32h
falco-daemonset-d8dnh                      1/1     Running                 0          32h
falco-daemonset-db7vg                      1/1     Running                 1          32h
falco-daemonset-kr8wj                      1/1     Running                 0          32h
falco-daemonset-vdsb6                      1/1     Running                 2          32h
lumpy--koala                               0/1     Init:CrashLoopBackOff   3695       20d
nginx-864459b57d-zqgjt                     1/1     Running                 0          21h
single-nginx-deployment-69dd5c845f-5znk9   1/1     Running                 0          44d
single-nginx-deployment-69dd5c845f-85vvr   0/1     ContainerCreating       0          21h
single-nginx-deployment-69dd5c845f-cdkfc   1/1     Running                 0          21d
test

Kubectl 日志输出详细程度和调试

Kubectl 日志输出详细程度是通过 -v 或者 --v 来控制的，参数后跟了一个数字表示日志的级别。Kubernetes 通用的日志习惯和相关的日志级别在这里有相应的描述。

详细程度	描述
–v=0	默认，始终对运维人员可见。
–v=1	如果您不想要详细程度，则为合理的默认日志级别
–v=2	有关服务的有用稳定状态信息以及可能与系统中的重大更改相关的重要日志消息。这是大多数系统的建议默认日志级别。
–v=3	有关更改的扩展信息。
–v=4	Debug 级别
–v=6	显示请求的资源。
–v=7	显示 HTTP 请求头
–v=8	显示 HTTP 请求内容
–v=9	显示 HTTP 请求内容而不截断内容

Volcano PodGroup认识

Kubernetes工作负载与服务介绍

Pod与工作负载的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6i2TFsP7-1650714444501)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

关键工作负载-ReplicaSet

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7sHu13Uf-1650714444501)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

关键工作负载-Deployment

关键工作负载-StatefulSet

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-glTPDmas-1650714444502)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

关键工作负载-DaemonSet

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V3RmCEhx-1650714444503)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

关键工作负载-Job

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D5baabWX-1650714444504)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

Kubernetes关键概念-CustomResourceDefinition

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aT8QKLfF-1650714444504)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

Pod与服务的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-X7Qq43GZ-1650714444504)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

Service

Service类型： ClusterIP、 NodePort、 LoadBalancer

Ingress

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iT4NdinF-1650714444505)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

参考链接：

https://blog.csdn.net/fly910905/article/details/103758149

https://mp.weixin.qq.com/s/dG5EYOJqe8N1T9u6Xjw7tQ

https://kubernetes.io/zh/docs/concepts/workloads/

https://edu.aliyun.com/lesson_1651_18354#_18354

https://edu.aliyun.com/lesson_1651_18353#_18353

， NodePort以及LoadBalancer三种类型

Service类型： ClusterIP、 NodePort、 LoadBalancer

Ingress

[外链图片转存中…(img-iT4NdinF-1650714444505)]

参考链接：

https://blog.csdn.net/fly910905/article/details/103758149

https://mp.weixin.qq.com/s/dG5EYOJqe8N1T9u6Xjw7tQ

https://kubernetes.io/zh/docs/concepts/workloads/

https://edu.aliyun.com/lesson_1651_18354#_18354

https://edu.aliyun.com/lesson_1651_18353#_18353

https://cloud.tencent.com/developer/inventory/11453

K8S实战系列2：Pod、工作负载与服务

文章系列

回顾

容器，其实是一种特殊的进程而已。

Kubernetes 是云原生时代的操作系统

Kubernetes Pod详解

Kubernets概览

Kubernetes关键概念-Pod

1. Pod详解-容器

使用 Init 容器

Init 容器示例

容器基本组成

2. Pod详解-资源需求和QoS

资源请求和限制的原理

CPU和内存请求和限制的目的

如果你没有指定CPU和内存限制

如果你设置了 CPU 限制和内存但未设置 CPU 请求和内存

QoS

QoS 类为 Guaranteed的 Pod

QoS 类为 Burstable 的 Pod

QoS 类为 BestEffort 的 Pod

不同的 QoS 表现

QoS 应用场景之一：Eviction

资源配额的工作方式：

如何满足 Pod 资源要求？

资源请求和限制的生产建议

3. Pod详解-健康检查

三种探针Probe

三种健康检查方法

配置探测器

4. Pod详解-配置文件

5. Pod详解-持久化存储

volume存储

1. 公/私有云驱动接口

2. 开源存储驱动接口

3. 本地临时存储

4. kubernetes对象API驱动接口

PV，PVC和StorageClass

pv, pvc和storageclass关系

6. Pod详解-服务域名发现

如何快速编写yaml文件

通过定义模版快速生成

explain命令

Kubectl接口调试

Kubectl 日志输出详细程度和调试

Volcano PodGroup认识

Kubernetes工作负载与服务介绍

Pod与工作负载的关系

关键工作负载-ReplicaSet

关键工作负载-Deployment

关键工作负载-StatefulSet

关键工作负载-DaemonSet

关键工作负载-Job

Kubernetes关键概念-CustomResourceDefinition

Pod与服务的关系

Service

Service类型： ClusterIP、 NodePort、 LoadBalancer

Ingress

参考链接：

Service类型： ClusterIP、 NodePort、 LoadBalancer

Ingress

参考链接：