MyLinuxOPS

ReplicaSet属于apps群组v1版本，早期大多数控制器都位于extensions/v1beta1，v1beta2,… ReplicaSet工作流程在Controller Manager中有一段代码称为ReplicaSet的控制器代码(Controller loop)。而控制器代码需要真正工作起来需要创建出对应的ReplicaSet Object，ReplicaSet Object是用于向API Server请求管理Pod对象（标签选择器选定的对象），如果存在此标签选择器选定的对象，且足量则无需创建，若没有ReplicaSet会借助于控制循环中的代码向APIserver创建出新的Pod，Pod来自于模板定义。然后由Scheduler调度并绑定至某节点，而后pod由kubelet来负责运行。 ReplicaSet资源定义规范12345678910111213141516apiVersion: apps/v1kind: ReplicaSetmetadata: name: … namespace: …spec: minReadySeconds <integer> # ...

在pod上直接使用Pod存储卷分为两步 在pod的Volumes字段上定义存储卷名称及存储卷 在容器内部挂载Volumes字段中所定义的存储卷。 emptyDir类型emptyDir类型的存储卷不可持久存储，其生命周期和容器生命周期相同。 emptyDir示例1.创建配置清单 1234567891011121314151617181920212223242526272829root@k8s-master01:~/yaml/chapter05# vim volumes-empyterdir-demo.yamlapiVersion: v1kind: Podmetadata: name: volumes-emptydir-demo namespace: defaultspec: initContainers: - name: config-file-downloader image: ikubernetes/admin-box imagePullPolicy: IfNotPresent command: ["/bin/sh","-c ...

ceph存储类资源清单示例： 123456789101112131415161718apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: fast-rbdprovisioner: kubernetes.io/rbdparameters: monitors: ceph01.ilinux.io:6789,ceph02.ilinux.io:6789,ceph03.ilinux.io:6789 adminId: admin adminSecretName: ceph-admin-secret adminSecretNamespace: kube-system pool: kube userId: kube userSecretName: ceph-kube-secret userSecretNamespace: kube-system fsType: ext4 imageFormat: "2" imageFeatures: "layering"reclaimP ...

本示例中会创建多个pv、pvc示例以验证pvc在挑选pvc时的策略，pv所使用的后端存储为nfs。 创建nfs共享目录在nfs-server上创建出共享的目录 1234567891011121314151617181920212223242526272829303132# 创建出目录[root@nfs ~]# mkdir /data/redis00{1,2,3,4,5}# 修改nfs配置文件[root@nfs data]# vim /etc/exports/data/redis 172.16.11.0/24(rw)/data/redis001 172.16.11.0/24(rw)/data/redis002 172.16.11.0/24(rw)/data/redis003 172.16.11.0/24(rw)/data/redis004 172.16.11.0/24(rw)/data/redis005 172.16.11.0/24(rw)# 重新导出目录[root@nfs data]# exportfs -ar[root@nfs data]# ex ...

Longhorn部署完毕后会自动创建出StorageClass，我们只需要创建pvc即可，需要注意longhorn的pvc默认删除策略为delete，如果需要保留则需要手动将其StorageClass内的策略改为Retain。 创建pvc1.编写pvc资源清单 123456789101112131415root@k8s-master01:~/yaml/chapter05# vim pvc-dyn-longhon-demo.yamlapiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-dyn-longhorn-demo namespace: defaultspec: accessModes: ["ReadWriteOnce"] volumeMode: Filesystem resources: requests: storage: 2Gi limits: storage: 10Gi storageClassName: longhorn 2.应用清单 123 ...

在k8s中除了使用secret和configMap向容器注入配置和敏感信息外，应用程序有时还需要基于其所运行的外在环境（如运行在哪个宿主机之上，宿主机的IP地址等）来了解自己的运行特性。 downwardAPI存储卷类型，从严格意义上来说，downwardAPI不是存储卷，它自身就存在。原因在于，它引用的是Pod自身的运行环境信息，这些信息在Pod启动后就存在。 类似于ConfigMap或Secret资源，容器能够在环境变量中在valueFrom字段中嵌套fieldRef或resourceFieldRef字段来引用其所属Pod对象的元数据信息。不过，通常只有常量类型的属性才能够通过环境变量注入到容器中，毕竟，在进程启动完成后无法再向其告知变量值的变动，于是，环境变量也就不支持中途的更新操作。 DownwardAPI引用DownwardAPI的引用分为两类 第一类容器规范中可在环境变量配置中的valueFrom通过内嵌字段fieldRef引用的信息包括如下这些： 12345metadata.name：Pod对象的名称；metadata.namespace：Pod对象隶属的名称空间；met ...

Secret详解ConfigMap可以向Pod内部注入配置信息，但是使用kubectl describe可以很轻易的看到配置信息，所以这对于向pod中的应用传敏感数据时就不太适用了。因而k8s提供了一种Secret资源来将敏感信息实施转换后再保存，而后每次被注入到Pod容器时自动解码，完成信息的还原。Secret资源是以非加密的形式存储于k8s的api-server后端的etcd中，即便做了转换其也不过是做了base64编码。 Secret的类型ConfigMap的配置信息基本没有类别之分，但Secret有所不同，根据其用户存在类型的概念； docker-registry：专用于让kubelet启动Pod时从私有镜像仓库pull镜像时，首先认证到Registry时使用； tls：专门用于保存tls/ssl用到证书和配对儿的私钥； generic：余下的通用类型 generic类型的Secretgemeric通用类型； 可以存在子类型： --type="kubernetes.io/basic-auth"：适用于web端的basic认证 --type=" ...

在k8s上还存在3个特殊的存储卷，ConfigMap、Secret和DownwardAPI。 ConfigMap用来向容器注入配置信息。 Secret同ConfigMap一样也是用来向容器注入配置信息，但是其注入信息时进行了base64的编码，用来向容器注入一些敏感信息 DownwardAPI用来将Pod所运行的外部的一些元数据信息注入到Pod内部，如当前容器运行的pod的名称，Pod的资源限制等等。 容器的配置信息docker为容器化应用提供配置信息的方法有4种： 启动容器时，直接向应用容器传递参数，args: [] 将定义好的配置文件焙进镜像中 通过环境变量向容器传递配置数据，这种方法有个前提，应用得支持从环境变量加载配置信息。 制作镜像时使用entrypoint脚本来预处理变量，常见的做法是使用非交互式编辑工具，将环境变量的值替换到应用配置文件中。 基于存储卷向容器传递配置文件。 运行中的改变，需要由应用程序重载。 k8s为容器提供配置信息的方法 使用ConfigMap，以k/v格式保存配置项的名称和配置数据；而后由pod中的容器以环境变量的方式从ConfigMap中加载 ...

ceph中的rbd支持动态预配，但kubeadm部署的k8s集群，却不支持该功能，原因在于kube-controller-manager镜像内部未内置ceph客户端工具。 需要自己手动重打kube-controller-manager镜像将ceph客户端工具打入后，重新运行 123456789ARG KUBE_VERSION="v1.19.4"FROM registry.aliyuncs.com/google_containers/kube-controller-manager:${KUBE_VERSION}RUN apt update && apt install -y wget gnupg lsb-releaseARG CEPH_VERSION="octopus"RUN wget -q -O - https://mirrors.aliyun.com/ceph/keys/release.asc | apt-key add - && \ echo deb https://mirror ...

在k8s上如果直接在pod上，以Volumes的形式定义存储卷然后挂载，那就要求所有使用挂载卷的用户必须对所使用的存储有所了解，否则用户将无法使用存储卷。k8s为了解决这种使用门槛，从而引入了PV和PVC的概念，让用户无需直接面对存储。 PV和PVC概念PVC：Persistent Volume Claim，持久卷申请，简称PVC；k8s上标准的资源类型之一；由用户使用；名称空间级别； PV：Persistent Volume，持久卷，可被PVC绑定；而PV一定要与某个真正的存储空间（一般是网络存储服务上的存储空间）对应起来，才能真正存储数据。由集群管理员负责管理。集群级别。 pv和pvc的使用逻辑 为了更方便用户的使用，k8s在存储卷上加入了中间层，用户需要使用存储卷时，只需要向PVC申请所需要的存储卷大小和相关参数，PVC会从后端的PV中自动挑出一个符合的PV将其绑定到pod之上。但是这种方式还存在一个弊端，PV必须要预先创建好，如果PV没有创建，那么PVC将无法从后段的PV中跳出可用的存储。从而让容器处于pending状态。 k8s为了解决上述问题，还引入了Storage Cl ...