在 K8s 中如何使用存储卷的详细介绍
PersistentVolume(PV)和PersistentVolumeClaim(PVC)这两个概念用于pod和volume之间解耦。Pod根据自己的需要提出数据卷的申请,k8s系统将符合条件的数据卷返回给pod。这样一来pod就无需直接和数据卷本身强绑定了。Pod无需知道数据卷的细节信息,比如具体用的是什么存储。 Pod中对数据卷的申请为PVC,用来和PVC绑定的数据卷称为PV。 PV可以有多种存储方式,比如NFS,iSCSI等。 PVC是使用PV资源的声明。 PVC和PV的关系是一对一的, 不能将多个PVC绑定到同一个PV上.PV和PVC的生命周期 供应阶段PV有两种供应方式 static 静态方式由系统管理员创建PV dynamic 如果没有静态的PV。系统会动态创建出PV来满足PVC。PV的提供者为StorageClass。要使用动态供应,PVC必须要指定一个StorageClass。如果StorageClass设置为空,那么针对这个PVC的动态供应特性会被禁用。 绑定阶段这个阶段指的是PV和PVC绑定的过程。系统有一个机制,循环检查新创建的PVC,然后找到一个符...
K8s 中遇到的错误总结
cannot create resource ERROR: Job failed (system failure): pods is forbidden: User “system:serviceaccount:dev:default” cannot create resource “pods” in API group “” in the namespace “xxx” 权限不够, 可能后面还会跟个clusterrole at scope..., 需要创建一个clusterrolebindind进行授权 上面例子中, system:serviceaccount是什么类型的对象, dev是namespace, default是用户, 而API group是核心组 http error: ResponseCode: 503 loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: failed to retrieve openAPI spec, http error: ResponseCode...
K8s 之安全认证
摘自:https://blog.csdn.net/hancoder/article/details/118070296 访问控制概述 Kubernetes作为一个分布式集群的管理工具,保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 在Kubernetes集群中,客户端通常有两类: User Account:一般是独立于kubernetes之外的其他服务管理的用户账号。 Service Account:kubernetes管理的账号,用于为Pod中的服务进程在访问Kubernetes时提供身份标识。 认证、授权与准入控制 ApiServer是访问及管理资源对象的唯一入口。任何一个请求访问ApiServer,都要经过下面三个流程: Authentication(认证):身份鉴别,只有正确的账号才能够通过认证 Authorization(授权): 判断用户是否有权限对访问的资源执行特定的动作 Admission Control(准入控制):用于补充授权机制以实现更加精细的访问控制功能。 认证管理...
StatefulSet 的使用
StatefulSet和Deployment控制器的区别 statefulSet下的Pod有DNS地址,通过解析Pod的DNS可以返回Pod的IP deployment下的Pod没有DNS 通过StatefulSet和headless service部署的服务效果 为什么要用headless service+statefulSet部署有状态应用?使用headless service+statefulSet可以实现 StatefulSet会为关联的Pod保持一个不变的Pod Name,其hostname格式为$(StatefulSet name)-$(序号【从0开始】) StatefulSet关联到的每一个Pod分配一个dnsName$<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local headless service会为关联的statefulSet分配一个域,通过dns解析该域能获取到每个pod的ip+port<service name>.$<na...
优雅停止(Graceful Shutdown)与 502/504 报错
优雅退出,业务侧需要做的任务是处理SIGTERM信号 如果 Pod 正在处理大量请求(比如 1000 QPS+)时,因为节点故障或「竞价节点」被回收等原因被重新调度,可能会观察到在容器被 terminate 的一段时间内出现少量 502/504。 为了搞清楚这个问题,需要先理解清楚 terminate 一个 Pod 的流程: 123451、Pod 被删除,状态置为 Terminating。kube-proxy 更新转发规则,将 Pod 从 service 的 endpoint 列表中摘除掉,新的流量不再转发到该 Pod。2、如果 Pod 配置了 preStop Hook ,将会执行。3、kubelet 对 Pod 中各个 container 发送 SIGTERM 信号以通知容器进程开始优雅停止。4、等待容器进程完全停止,如果在 terminationGracePeriodSeconds 内 (默认 30s) 还未完全停止,就发送 SIGKILL 信号强制杀死进程。5、所有容器进程终止,清理 Pod 资源。 注意:1和2 两个工作是异步发生的,所以在未设置 preSt...
关于 DNS 解析的一些认识
Kubernetes 中的 DNS在 Kubernetes 中,服务发现有几种方式:①:基于环境变量的方式②:基于内部域名的方式 基本上,使用环境变量的方式很少,主要还是使用内部域名这种服务发现的方式。 其中,基于内部域名的方式,涉及到 Kubernetes 内部域名的解析,而 kubedns,是 Kubernetes 官方的 DNS 解析组件。从 1.11 版本开始,kubeadm 已经使用第三方的 CoreDNS 替换官方的 kubedns 作为 Kubernetes 集群的内部域名解析组件,我们的重点,是 CoreDNS,但是在开始 CoreDNS 之前,需要先了解下 kubedns Kubernetes 中的域名是如何解析的在 Kubernetes 中,比如服务 a 访问服务 b,对于同一个 Namespace下,可以直接在 pod 中,通过 curl b 来访问。对于跨 Namespace 的情况,服务名后边对应 Namespace即可。比如 curl b.default。那么,使用者这里边会有几个问题: ①:服务名是什么?②:为什么同一个 Namespace 下,直...
标签、污点与容忍以及驱逐维护
污点与容忍 亲和性/反亲和性无论是硬策略还是软策略方式,都是调度 pod 到预期节点上,而Taints恰好与之相反,如果一个节点标记为 Taints ,除非 pod 也被标识为可以容忍污点节点,否则该 Taints 节点不会被调度 pod。 污点:taints 容忍:tolerations 污点策略污点策略有以下选项: NoSchedule:表示 pod 不会被调度到标记为 taints 的节点 PreferNoSchedule:NoSchedule 的软策略版本,表示尽量不调度到污点节点上去 NoExecute:该选项意味着一旦 Taint 生效,如该节点内正在运行的 pod 没有对应 Tolerate 设置,会直接被逐出 污点 taint 标记节点的命令如下: 12$ kubectl taint nodes node02 test=node02:NoSchedulenode "node02" tainted 容忍上面的命名将 node02 节点标记为了污点,影响策略是 NoSchedule,只会影响新的 pod 调度,如果仍然希望...
Docker 命令记录(长期)
Docker命令大全配置docker登陆时命令非明文环境变量的登录方式(通过/etc/profile设置PASSWORD变量),以下示例从变量读取密码,然后使用STDIN将其传递给docker login命令: 1echo "$PASSWORD" | docker login --username <xxx> --password-stdin ${REGISTRY_ADDRESS} Docker命令记录(长期)ctr为镜像打tag1ctr images tag oldimage:v1 newimage:v2 docker为镜像打tag1docker tag oldimage:v1 newimage:v2 从容器里面拷文件到宿主机1docker cp 容器名:要拷贝的文件在容器里面的路径 要拷贝到宿主机的相应路径 从宿主机拷文件到docker容器里面1docker cp 要拷贝的文件路径 容器名:要拷贝到容器里面对应的路径 docker内部安装工具/插件/软件123456需要知道docker是一个最小体积...
Dockerfile 参数详解
Dockerfile什么是 Dockerfile1Dockerfile 是一个用来构建镜像的文本文件,文本内容包含了一条条构建镜像所需的指令和说明。 Dockerfile的作用123安装dockerfile中的指令定义docker容器或者容器中的应用程序以及服务Dockerfile制作一个镜像模板安装模板统一生成容器Dockerfile 中每一个指令都会建立一层 Dockerfile的基础结构12345#开头的表示注释行,说明dockerfile中的指令维护者的信息镜像操作指令容器操作指令基础镜像信息 Dockerfile中常见的操作指令和作用1234567891011121314151617181920212223242526272829FROM:指定创建镜像的基础镜像MAINTAINER:Dockerfile作者信息,一般写的是联系方式RUN:运行Linux系统的命令使用CMD:指定容器启动执行的命令;启动容器中的服务LABEL:指定生成镜像的源数据标签EXPOSE:指定镜像容器监听端口号;发布服务使用ENV:使用环境变量ADD:对压缩文件进行解压缩;将数据移动到指定的...
ENTRYPOINT 和 CMD
ENTRYPOINT和CMD都是让用户指定一个可执行程序, 这个可执行程序在container启动后自动启动 执行运行一个没有调用ENTRYPOINT或者CMD的docker镜像, 一定返回错误 12$ docker run alpineFATA[0000] Error response from daemon: No command specified 覆盖 首先两者都可以执行命令覆盖, 覆盖的情况如下 在写Dockerfile时, ENTRYPOINT或者CMD命令会自动覆盖基础镜像的ENTRYPOINT或者CMD命令. 在docker镜像运行时, 用户也可以在命令指定具体命令, 覆盖在Dockerfile里的命令. CMD: CMD命令可以直接接命令进行覆盖ENTRYPOINT: 使用--entrypoint参数覆盖默认的ENTRYPOINT 因为CMD命令很容易被docker run命令的方式覆盖, 所以, 如果你希望你的docker镜像的功能足够灵活, 建议在Dockerfile里调用CMD命令 执行命令的两种方法shell表示法:1CMD exe...
