spec

1.6多个查询字段（常量条件） 多个查询字段的查询处理逻辑如下所示： JOIN:prepare阶段 setup_tables()：同1.1测试。 setup_fields()：同1.1测试。 setup_conds()：同1.4测试。 JOIN:optimize阶段 optimize_cond()：类似1.4测试，不同之处在于查询的where条件中有恒等常量，在优化过程中会调用remove_eq_conds将1=1条件删除。 make_join_statistics()：与1.4测试类似，由于where条件查询有两个，并且其中一个条件可以通过索引查询。因此首先通过调用update_ref_and_keys()（sql\sql_select.cc:3967）函数，查找可以使用索引的字段。 SQL_SELECT::test_quick_select()：同1.5索引测试 get_key_scans_params()：同1.5索引测试。 choose_plan()：同1.3测试。 greedy_search()：同1.3测试。 best_extension_by_limited_search()：同1.5索引测试。 JOIN:exec阶段 以下操作同1.3测试。 通过测试可以看出，对于常量等式对查询优化器来说没有任何意义，会在optimize_conds时将常量等式删除

StorageClass 之前我们部署了 PV 和 PVC 的使用方法，但是前面的 PV 都是静态的，什么意思？就是我要使用的一个 PVC 的话就必须手动去创建一个 PV ，我们也说过这种方式在很大程度上并不能满足我们的需求，比如我们有一个应用需要对存储的并发度要求比较高，而另外一个应用对读写速度又要求比较高，特别是对于 StatefulSet 类型的应用简单的来使用静态的 PV 就很不合适了，这种情况下我们就需要用到动态 PV ，也就是我们今天要讲解的 StorageClass 。 创建 要使用 StorageClass ，我们就得安装对应的自动配置程序，比如我们这里存储后端使用的是 nfs ，那么我们就需要使用到一个 nfs-client 的自动配置程序，我们也叫它 Provisioner ，这个程序使用我们已经配置好的 nfs 服务器，来自动创建持久卷，也就是自动帮我们创建 PV 。 自动创建的 PV 以 ${namespace}-${pvcName}-${pvName} 这样的命名格式创建在 NFS 服务器上的共享数据目录中 而当这个 PV 被回收后会以 archieved-${namespace}-${pvcName}-${pvName} 这样的命名格式存在 NFS 服务器上。 当然在部署 nfs-client 之前，我们需要先成功安装上 nfs 服务器

对于DockerFile中的CMD [“”] 以及ENTRYPOINT[“xxx”, “xxxx”]以及kubernetes中的command Args的描述一直很困惑，特别是针对外网下载的image,进行调试验证的时候。需要弄清楚DockerFile与Kubernetes yaml中定义的关系。 其实kubernetes社区已经给出了明确的说明 This table summarizes the field names used by Docker and Kubernetes. Description Docker field name Kubernetes field name The command run by the container Entrypoint command The arguments passed to the command Cmd args When you override the default Entrypoint and Cmd, these rules apply: If you do not supply command or args for a Container, the defaults defined in the Docker image are used. If you supply a command but no

有状态应用编排 StatefulSet 本文将主要分享以下四方面的内容： “有状态”需求 用例解读 操作演示 架构设计 “有状态”需求 课程回顾 我们之前讲到过 Deployment 作为一个应用编排管理工具，它为我们提供了哪些功能？ 如下图所示： 首先它支持定义一组 Pod 的期望数量，Controller 会为我们维持 Pod 的数量在期望的版本以及期望的数量； 第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照我们给出的策略来更新 Pod，同时在更新的过程中，也会保证不可用 Pod 数量在我们定义的范围内； 第三，如果我们在发布的过程中遇到问题，Deployment 也支持一键来回滚。 可以简单地说， Deployment 认为：它管理的所有相同版本的 Pod 都是一模一样的副本。 也就是说，在 Deployment Controller 看来，所有相同版本的 Pod，不管是里面部署的应用还是行为，都是完全相同的。 这样一种能力对于无状态应用是支持满足的，如果我们遇到一些有状态应用呢？ 需求分析 比如下图所示的一些需求： 以上的这些需求都是 Deployment 无法满足的，因此 Kubernetes 社区为我们提供了一个叫 StatefulSet 的资源，用来管理有状态应用。 StatefulSet：主要面向有状态应用管理的控制器

RPMBUILD(8) System Manager's Manual RPMBUILD(8) 名字 rpmbuild - 创建 RPM 包 语法 创建包 rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [rpmbuild-options] SPECFILE ... rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} [rpmbuild-options] TARBALL ... rpmbuild {--rebuild|--recompile} SOURCEPKG ... 其他 rpmbuild --showrc rpmbuild-options [--buildroot DIRECTORY] [--clean] [--nobuild] [--rmsource] [--rmspec] [--short-circuit] [--noclean] [--nocheck] [--target PLATFORM] 描述 rpmbuild 用于创建软件的二进制包和源代码包。 一个"包"包括文件的归档以及用来安装和卸载归档中文件的元数据。 元数据包括辅助脚本、文件属性、以及相关的描述性信息。 软件包有两种： 二进制包，用来封装已经编译好的二进制文件； 源代码包，用来封装源代码和要构建二进制包需要的信息。 必须选择下列"模式"之一： (1)从

前言 拥抱开源，无私分享，共享技术，相互学习，共同进步，分享更多有深度的文章，欢迎转发分享 四层负载均衡调度器service回顾 使用四层负载均衡调度器service时，当客户端访问kubernetes集群内部的应用时，数据包走向如下面流程所示 client--->nodeip:port--->service ip:port--->podip:port 客户端-->node节点的ip:端口--->service的ip:端口--->pod的ip:端口 1.Ingress Controller Ingress Controller是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，由七层负载均衡器在反向代理到后端pod，常见的七层负载均衡器有nginx，traefik等，以我们熟悉的nginx为例，假如请求到达nginx，会通过upstream反向代理到后端pod，但是后端pod的ip地址是一直在变化的，因此在后端pod前需要加一个service，这个service只是起到分组的作用，那么我们upstream只需要填写service地址即可 nginx：需要手动加载配置文件 traefik：定期自动加载配置文件，不需要手动干预，在微服务中几乎都会使用这种调度器 2.Ingress 官方： https://kubernetes.io/docs/concepts

前言 拥抱开源，无私分享，共享技术，相互学习，共同进步，分享更多有深度的文章，欢迎转发分享 四层负载均衡调度器service回顾 使用四层负载均衡调度器service时，当客户端访问kubernetes集群内部的应用时，数据包走向如下面流程所示 client--->nodeip:port--->service ip:port--->podip:port 客户端-->node节点的ip:端口--->service的ip:端口--->pod的ip:端口 1.Ingress Controller Ingress Controller是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，由七层负载均衡器在反向代理到后端pod，常见的七层负载均衡器有nginx，traefik等，以我们熟悉的nginx为例，假如请求到达nginx，会通过upstream反向代理到后端pod，但是后端pod的ip地址是一直在变化的，因此在后端pod前需要加一个service，这个service只是起到分组的作用，那么我们upstream只需要填写service地址即可 nginx：需要手动加载配置文件 traefik：定期自动加载配置文件，不需要手动干预，在微服务中几乎都会使用这种调度器 2.Ingress 官方： https://kubernetes.io/docs/concepts

kubernetes 的调度 标签（空格分隔）： kubernetes系列 一： kubernetes的调度 二： kubernetes的节点的亲和性 三： kubernetes的污点与容忍 四： kubernetes的固定节点 一：kubernetes的调度 1.1 scheduler 的介绍 Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。听起来非常简单，但有很多要考虑的问题： 1.公平：如何保证每个节点都能被分配资源 2. 资源高效利用：集群所有资源最大化被使用 3. 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作 4. 灵活：允许用户根据自己的需求控制调度的逻辑 Sheduler 是作为单独的程序运行的，启动之后会一直坚挺 API Server，获取 PodSpec.NodeName 为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上 1.2 调度过程 调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为 predicate ；然后对通过的节点按照优先级排序，这个是 priority；最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误 Predicate 有一系列的算法可以使用： PodFitsResources

kubernetes 的pv/pvc存储 标签（空格分隔）： kubernetes系列 一： kubernetes的PV/PVC存储 一： kubernetes的PV/PVC存储 1.1 pv PersistentVolume （PV） 是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、 iSCSI 或特定于云供应商的存储系统 1.2 pvc PersistentVolumeClaim （PVC） 是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源 （CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载） 1.3 静态 pv 集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用 于消费 1.4 动态 当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此 配置基于 StorageClasses ：PVC 必须请求 [存储类]

转载：https://blog.51cto.com/hmtk520/2428519 一、Pod简介 二、标签 三、Pod控制器：Deployment、ReplicaController、StatefuleSet、DaemonSet、Job、CronJob等 四、Service 五、Ingress 六、ServiceAccount/UserAccount 七、Secret&Configmap 一、Pod简介 k8s的常见资源： workload（对外提供服务的）：Pod、ReplicaSet、Deployment、StaefulSet、Job、CronJob... Service发现及均衡：service、ingress 配置与存储：Volume、CSI(存储接口) 　　　　　　ConfigMap、Secret、DownwardAPI 集群级资源：Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding 元数据资源：HPA、PodTemplate、LimitRange、 一个Pod（就像一群鲸鱼，或者一个豌豆夹）相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用