小五的个人杂货铺

Dckr<谨供参考> 最近发现个好东西-Dckr : 一款基于Docker的容器配置及编排的向导式构建工具（支持Docker、Compose、Kubernets、Rancher的资源文件向导式构建） 引自官方: 12345678910111213通过它，你可以轻松完成以下操作： 借助语义化UI向导式构建Dockerfile、docker-compose.yaml、Kubernetes资源文件、Rancher Chart。 支持docker-compose.yaml向Kubernetes资源文件的转换。 支持docker-compose.yaml或Kubernetest（Helm Chart）向Rancher Chart的转换。它的存在意义： 通过语义化UI向导式的指引你去构建相关容器配置、编排文件，降低了你的学习成本。 通过转换功能，能轻松地将不同容器产品的配置文件进行相互转换，极大地提高了你的工作效率。 通过它进行构建的YAML文件是符合规范的，让你摆脱编写YAML文件因缩进等格式问题带来的痛苦。 ...

k8s集群中创建一个名为hello的service，就会生成一个同名的endpoint对象，ENDPOINTS就是service关联的pod的ip地址和端口, 即动态存储pod ip地址和端口对应关系的list,Kubernetes在创建Service时，根据Service的标签选择器（Label Selector）来查找Pod，据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时，EndPoints也随之变化。Service接收到请求时，就能通过EndPoints找到请求转发的目标地址endpoint不可以用来固定podip,endpoint是随着pod的改变而改变,而非pod随着endpoint的改变而改变 手动创建 Endpoint 创建service: 略 创建一个 endpoint.yaml 文件，内容如下(注意替换ip为你容器访问ip(pod ip))： 12345678910apiVersion: v1kind: Endpointsmetadata: name: nginxsubsets: - addresses: -...

HPA我们可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标–自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。 HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理 注: 在 K8S 1.18之前，HPA 扩容是无法调整灵敏度的 对于缩容，由 kube-controller-manager 的 --horizontal-pod-autoscaler-downscale-stabilization-window 参数控制缩容时间窗口，默认 5 分钟，即负载减小后至少需要等 5 分钟才会缩容。 对于扩容，由...

k8s deployment文件属性简介12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667apiVersion: apps/v1 #指定api版本，此值必须在k8s api-versions中kind: Deployment # 指定创建资源的角色/类型metadata: # 资源的元数据/属性 name: # 资源的名字，在同一个namespace中必须唯一 namespace: # 部署在哪个namespace中spec: # 资源规范字段 strategy: # 策略 type: RollingUpdate # 滚动更新策略 selector: # 选择器 matchLabels: # 匹配标签 app: replicas: 1 # 声明副本数目 template: # 模版 metadata: # 资源的元数据/属性 ...

Kubernetes 自己提供了 secret 这种方式，但其是一种编码方式，而非加密方式，如果需要用版本控制系统（比如 git）来对所有的文件、内容等进行版本控制时，这种用编码来处理敏感信息的方式就显得很不安全了（即使是采用私有库），这一点在实现 GitOps 时，是一个痛点。 Sealed Secrets Sealed Secrets 充分利用 kuberntes 的高扩展性，通过 CRD 来创建一个 SealedSecret 对象，通过将加密的内容存储在扩展 SealedSecret 对象中，而 SealedSecret 只能够被运行于目标集群上的 controller 解密，其他人员和方式都无法正确解密原始数据。SealedSecret 对象同时又会生成与其名称相同的 secret 对象，随后就可以按照常规方式使用 secret 对象了。最后将加密后的文件直接推送至版本控制系统即可，而不用担心敏感信息被泄漏. 简单来说就是, 我们需要用 YAML 的形式生成一个 Secret，但是我们希望 YAML 自身的内容是加密的，以保证传输过程中，Secret...

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...

在Pod中共享卷以供多方使用是很有用的。VolumeMounts.subPath属性可用于指定所引用的卷内的子路径，而不是其根路径。 subpath的两种使用场景 1个Pod中可以有多个容器，将不同容器的路径挂载在存储卷volume的子路径，这种场景需要使用到subpath。 volume支持将configMap/secret挂载到容器的路径，但是会覆盖容器路径下原有的文件。如何支持选定configmap/secret的key-value挂载到容器中，且不会覆盖掉原目录下的文件，这个时候可以用subpath。 一个pod多组容器的情况12345678910111213141516171819202122apiVersion: v1kind: Podmetadata: name: pod-subpath-yuhaohaospec: containers: - name: redis-container image: redis volumeMounts: - mountPath: /var/lib #...

仅删除1kubectl delete namespace <ns> 强制删除12# grace-period=0: 设置优雅删除时间为0kubectl delete namespace <ns> --force --grace-period=0 修改.spec.finalizer和metadata.finalizer字段12kubectl edit namespace cattle-system查找finalizers,将后面的值置为[] 通过k8s提供的api接口，修改.spec.finalizers和metadata.finalizer字段,将后面的值置为[]，从而k8s会直接将该ns删除1234561. kubectl get namespace <ns> -o json > xx.json2. 编辑该xx.json文件，修改.spec.finalizers字段,将后面的值置为[]3. 另开一个终端，开启k8s apiserver的一个http代理，以免必须带上证书才能访问: kubectl proxy --port=80814....

现象 系统的商户端出现响应慢，加载慢的问题 关于慢调用问题 可能带来的危害包括： 前端业务维度：首先慢调用可能会引起前端加载慢的问题，前端加载慢可能会进一步导致应用卸载率高，进而影响品牌的口碑。 项目交付的维度：由于接口慢导致达不到 服务质量目标，进而导致项目延期。 业务架构稳定性：当接口调用慢时，非常容易引起超时，当其他业务服务都依赖这个接口，那么就会引发大量重试，进而导致资源耗尽，最终导致部分服务或者整个服务不可用的雪崩的现象。 问题排查 先排查下其他端是否也存在慢响应等问题，发现加载正常 检查网关日志(orange)，发现有大量status：499。 关于status code 499, client has closed...

externaltrafficpolicy作用阐述把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns...