Kubernets使用Ceph存储
环境介绍
名称
版本
系统版本
Centos 7.6
集群部署方式
Kubeadm
K8s集群版本
v1.18.3
ceph集群版本
v14.2.10
K8s使用RBD做为持久数据卷传统PV&PVC方式挂载RBD1.ceph创建存储池并启动RBD功能
12345678910111213# 创建存储池并启用[root@ceph-node01 ceph]# ceph osd pool create rbd 8 8pool 'rbd' created[root@ceph-node01 ceph]# ceph osd pool lsrbd[root@ceph-node01 ceph]# ceph osd pool application enable rbd rbdenabled application 'rbd' on pool 'rbd'# 创建一个镜像后面供pv-pvc使用[root@ceph-node01 ceph]# rbd create --size 10240 image[root@ce ...
四、Kubernetes学习笔记—资源清单
四、K8S资源清单1、资源的分类名称空间级别
工作负责型资源:Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob
服务发现及负责均衡资源:Service、Ingress
配置与存储型资源:Volume(存储卷)、CSI(容器存储接口)
特殊类型存储卷:ConfigMap(当配置中心用的资源类型)、Secret(保存敏感数据)、DownwardAPI(把外部环境中的信息输出给容器)。
集群级资源:Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
元数据型资源:HPA、PodTemplate、LimitRange
2、理解Kubernetes中的对象
在 Kubernetes 系统中,Kubernetes 对象 是持久化的条目。Kubernetes 使用这些条目去表示整个集群的状态。特别地,它们描述了如下信息
什么容器化应用在运行(以及在哪个 Node 上)
可以被应用使用的资源
关于应用如何表现的策略,比如重启策略、升级策略,以及容错策略 ...
五、Kubernetes学习笔记—资源控制器
五、K8S资源控制器Kubernetes中内建了很多控制器,这些相当于一个状态机制。用来控制pod的具体状态和行为。
1、控制器的类型
ReplicationController(RC)和ReplicaSet(RS)
Deployment
DaemonSet
StateFulSet
Job/CronJob
Horzontal Pod Autoscaling
1.1 RC和RS控制器ReplicationController(RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退 出,会自动创建新的 Pod 来替代;而如果异常多出来的容器也会自动回收;
在新版本的Kubernetes 中建议使用 ReplicaSet来取代 ReplicationController。ReplicaSet 跟ReplicationController没有本质的不同,只是名字不一样,并且 ReplicaSet支持集合式的 selector;
创建RS示例:
1234567891011121314151617181920212223apiVersion: apps/v1ki ...
六、Kubernetes学习笔记—Service与Ingress
六、Service与Igress6.1 Service6.1.1 service简介通过以前的学习,我们已经能够通过ReplicaSet来创建一组Pod来提供具有高可用性的服务。虽然每个Pod都会分配一个单独的Pod IP,然而却存在如下两问题:
Pod IP仅仅是集群内可见的虚拟IP,外部无法访问。
Pod IP会随着Pod的销毁而消失,当ReplicaSet对Pod进行动态伸缩时,Pod IP可能随时随地都会变化,这样对于我们访问这个服务带来了难度。
因此,Kubernetes中的Service对象就是解决以上问题的实现服务发现核心关键
Service可以看作是一组提供相同服务的Pod对外的访问接口,借助Service,应用可以方便地实现服务发现和负载均衡但是在使用上有以下限制:
只能提供四层负载均衡能力,而没有7层的功能,但有时我们可以能需要更多的匹配规则来转发请求,这点上4层负载均衡是不支持的。
Service同其他Kubernetes对象一样,也是通过yaml或json文件进行定义。此外,它和其他Controller对象一样,通过Label Selector来确定一个 ...
七、Kubernetes学习笔记—Volume、PV-PVC、configmap、secret
七、Volume与PV、PVC、ConfigMap7.1 Volume存储卷官网文档:https://kubernetes.io/zh/docs/concepts/storage/volumes/
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod 中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题
7.1.1 背景Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所f以,卷的生命比 Pod 中的所有容器都长,当这个容器重启时数据仍然得以保存。当然,当 Pod 不再存在时,卷也将不复存在。也许更重要的是,Kubernetes支持多种类型的卷,Pod 可以同时使用任意数量的卷
7.1.2 存储卷的类型1awsElasticBlockStore、azureDisk、azureFile、cephfs、cinder、configMap、c ...
八、Kubernetes学习笔记—Statefulset控制器,滚动更新及扩缩容
八、Statefulset控制器8.1 statefulset简介
从前面的学习我们知道使用Deployment创建的pod是无状态的,当挂载了Volume之后,如果该pod挂了,Replication Controller会再启动一个pod来保证可用性,但是由于pod是无状态的,pod挂了就会和之前的Volume的关系断开,新创建的Pod无法找到之前的Pod。但是对于用户而言,他们对底层的Pod挂了是没有感知的,但是当Pod挂了之后就无法再使用之前挂载的存储卷。
为了解决这一问题,就引入了StatefulSet用于保留Pod的状态信息。
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计),其应用场景包括:
1、稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
2、稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
3、有序部署, ...
九、Kubernetes学习笔记—集群认证授权和准入控制
九、集群认证授权与准入控制API Server作为Kubernetes网关,是访问和管理资源对象的唯一入口,其各种集群组件访问资源都需要经过网关才能进行正常访问和管理。每一次的访问请求都需要进行合法性的检验,其中包括身份验证、操作权限验证以及操作规范验证等,需要通过一系列验证通过之后才能访问或者存储数据到etcd当中。如下图:
9.1 Service AccountService account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同
User account是为人设计的,而service account则是为Pod中的进程调用Kubernetes API而设计;
User account是跨namespace的,而service account则是仅局限它所在的namespace;
每个namespace都会自动创建一个default service account
Token controller检测service account的创建,并为它们创建secret
开启ServiceAccount Admi ...
十、Kubernetes学习笔记—Dashboard及访问控制
十、dashboard部署及访问控制10.1 dashboard部署
项目地址:https://github.com/kubernetes/dashboard
本文中部署的是v2.0.0版本
123456789101112131415161718192021222324252627# 通过部署yaml文件直接部署[root@k8s-master dashbad]$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml[root@k8s-master dashbad]$ kubectl get pods -n kubernetes-dashboard NAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-c79c65bb7-s9qf5 1/1 Running 0 ...
十四、Kubernetes学习笔记—HPA与资源指标监控
十四、资源监控指标14.1 核心指标监控metrics-server在最初的系统资源监控,是通过cAdvisor去收集单个节点以及相关Pod资源的指标数据,但是这一功能仅能够满足单个节点,在集群日益庞大的过程中,该功能就显得low爆了。于是将各个节点的指标数据进行汇聚并通过一个借口进行向外暴露传送是必要的。
Heapster就是这样的一种方式,通过为集群提供指标API和实现并进行监控,它是集群级别的监控和事件数据的聚合工具,但是一个完备的Heapster监控体系是需要进行数据存储的,为此其解决方案就是引入了Influxdb作为后端数据的持久存储,Grafana作为可视化的接口。原理就是Heapster从各个节点上的cAdvisor采集数据并存储到Influxdb中,再由Grafana展示。原理图如下:
时代在变迁,陈旧的东西将会被淘汰,由于功能和系统发展的需求,Heapster无法满足k8s系统监控的需求,为此在Kubernetes 1.7版本以后引入了自定义指标(custom metrics API),在1.8版本引入了资源指标(resource metrics API)。逐渐地H ...
十三、Kubernetes学习笔记—Pod容器资源限制
十三、pod容器资源限制当你定义 Pod 时可以选择性地为每个 容器设定所需要的资源数量以及最大使用资源数量。 最常见的可设定资源是 CPU 和内存(RAM)大小;此外还有其他类型的资源。
当你为 Pod 中的 Container 指定了资源 请求 时(满足这个值Pod才会被调度到节点),调度器就利用该信息决定将 Pod 调度到哪个节点上。 当你还为 Container 指定了资源 约束 时(最大使用资源),kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 kubelet 还会为容器预留所 请求 数量的系统资源,供其使用。
13.1 请求资源和最大约束资源如果 Pod 运行所在的节点具有足够的可用资源,容器可能(且可以)使用超出对应资源 request 属性所设置的资源量。不过,容器不可以使用超出其资源 limit 属性所设置的资源量。
例如,如果你将容器的 memory 的请求量(request)设置为 256 MiB,而该容器所处的 Pod 被调度到一个具有 8 GiB 内存的节点上,并且该节点上没有其他 Pods 运行,那么该容器就可以尝试使用更多的内存(在没有设 ...