使用base64生成kubernetes使用的secret yaml

发表于2022-11-04|更新于2026-07-16|容器

先申请证书, 证书申请下来后会有证书 (一般都是 pem 后缀或者 crt 后缀) 和私钥 (一般后缀是 key)

使用 base64 加工一下:

1	base64 ./i.com_bundle.crt -w 0

-w 0 的意思是不换行, 默认是 76 个字符换行.

然后填到 Kubernetes 的 yaml 文件里面即可.

apiVersion: v1
data:
  tls.crt: <单行文本证书>
  tls.key: <单行文本key>
kind: Secret
metadata:
  name: lexus-ald-i-com
  namespace: prod-valet
type: kubernetes.io/tls

文章作者: 张理坤

文章链接: https://zahui.fan/posts/462d0642/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源杂烩饭！

相关推荐

Java程序被停止前自动dump内存快照

线上业务偶尔会出现重启现象，为了排查这个问题，决定在 OOM 的时候自动进行 dump 内存快照用于分析针对 JVM OOM 的情况OOM 全称 “Out Of Memory”，表示内存耗尽。当 JVM 因为没有足够的内存来为对象分配空间，并且垃圾回收器也已经没有空间可回收时，就会抛出这个错误，解决 OOM 问题的一个思路: 假设发生 OOM 了，必然说明系统中某个区域的对象太多了，塞满了那个区域，而且一定是无法回收掉那些对象，最终才会导致内存溢出的，首先就得知道到底是什么对象太多了导致 OOM ，就必须得有一份 JVM 发生 OOM 时的 dump 内存快照有了 dump 内存快照，就可以用 MAT 之类的工具，或者在线工具来分析：https://memory.console.heapdump.cn/JVM 在发生 OOM 的时候并不是直接挂掉的，而是在 OOM 之前会尽量去 GC 腾出来一些内存空间，如果 GC 后还是没有空间，放不下对象，才会触发内存溢出的。JVM 给我们提供了一些参数可以在发生 OOM 的时候进行自动 dump 内存快照。： -XX:+HeapDu...

Kubernetes之master高可用方案

之前一直用使用的负载方案是搭建一台负载均衡器，可以是 haproxy 或 nginx 或 lvs，来将多个 master 节点的 6443 端口做个负载均衡，但是考虑到负载均衡也需要高可用，所以会引入类似 keepalived 的方案来解决问题。偶然看到了 kubeasz 这个开源项目，宣称解决了 master 高可用问题，部署了一遍发现并没有额外搭建负载均衡器，研究了一下，发现了另一种思路。使用额外的负载均衡来做高可用这种就是比较容易想到的一种方案，比如 3 个 master 节点，前面有一台负载均衡（nginx、haproxy、lvs）等，但是负载均衡本身就是一个单点故障，所以一般来说还需要另一台负载均衡，通过 keepalived 来实现 VIP 的切换使用Keepalived来实现Nginx高可用使用Nginx做负载均衡使用HAproxy做负载均衡使用LVS做负载均衡vim nginx.conf 在文件最后添加然后 vim /etc/nginx/stream.conf 因为我们用 nginx 四层负载 ingress，需要监听 80 端口，与 nginx ...

Kubernetes 绑定Hosts的正确姿势

有的时候我们需要在容器里面绑定 hosts，比如我们用 logstash 需要消费 kafka 消息，但是 kafka 监听的地址是 hostname，这个时候就需要绑定 hosts（规范一点是做解析）在容器里面绑定 hosts 常见的方法一种是挂载主机的 hosts 文件，一种是修改容器的启动 CMD，每次启动修改 hosts，这两种方法都有个缺点，就是不受 kubelet 管理了，默认的 hosts 内容也会被覆盖掉在 k8s 环境下有更好的解决方案：那就是让 k8s 自己来管理使用 hostAliases 来绑定 hosts 进入容器查看 hosts 文件这个 hosts 包括两个部分，一部分是容器自带的 hosts，另一部分是我们自己添加的在 docker 下绑定 hosts运行时候修改docker 可以通过 –add-host 参数来添加 hosts 信息到容器的/etc/hosts 文件中构建时修改Dockerfile 中，可以在 CMD 命令下进行修改，在 RUN 里面修改会提示文件只读无法修改。在 docker-c...

kubernetes删除节点

删除 worker 节点设置节点不可调度，即不会有新的 pod 在该节点上创建 –delete-local-data: 即使 pod 使用了 emptyDir 也删除–ignore-daemonsets: 忽略 deamonset 控制器的 pod，如果不忽略，deamonset 控制器控制的 pod 被删除后可能马上又在此节点上启动起来,会成为死循环；–force: 不加 force 参数只会删除该 NODE 上由 ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job 创建的 Pod，加了后还会删除’裸奔的 pod’(没有绑定到任何 replication controller) kubectl delete node 172.16.21.26 删除 master 节点未完待续

Kubernetes的3中探针readinessProbe、livenessProbe和startupProbe

探针K8S 提供了 3 种探针 startupProbe 启动检查（1.16 版本新增）livenessProbe 存活检查readinessProbe 就绪检查 startupProbekubernetes 1.16 版本新增功能，用于判断容器内应用程序是否已经启动，如果配置了 startuprobe，就会先禁用其他的探测，直到它成功为止，成功后将不再进行探测。 readinessProbe一般用于探测容器内的程序是否健康，它的返回值如果为 success，那么就代表这个容器已经完成启动，并且程序已经是可以接受流量的状态. 这个时候就会被加到 service 的后端列表中，即可以对外提供服务。 livenessProbe用于探测容器是否运行，如果探测失败，kubelet 会根据配置的重启策略进行相应的处理，如果没有配置该探针，默认就是 success 检查方式httpgetkubelet 会向容器内运行的服务（服务在监听 8080 端口）发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet ...

找出占用Kubernetes节点磁盘的Pod

有部分开发不规范导致日志写入容器, 在 k8s 环境下导致节点磁盘空间占用过高, 解决方案有: 通过监控告警来提前预防挂载磁盘, 容器日志写入磁盘使用自动清理脚本 kubectl 查询每个 pod 占用磁盘空间使用 python 处理所有节点执行命令方式输出结果如图: Docker 相关操作查看容器磁盘占用