在 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...
公告