使用base64生成kubernetes使用的secret yaml

发表于2022-11-04|更新于2026-03-28|容器

|浏览量:

先申请证书, 证书申请下来后会有证书 (一般都是 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 许可协议。转载请注明来源杂烩饭！

相关推荐

Kubernetes 绑定Hosts的正确姿势

有的时候我们需要在容器里面绑定 hosts，比如我们用 logstash 需要消费 kafka 消息，但是 kafka 监听的地址是 hostname，这个时候就需要绑定 hosts（规范一点是做解析）在容器里面绑定 hosts 常见的方法一种是挂载主机的 hosts 文件，一种是修改容器的启动 CMD，每次启动修改 hosts，这两种方法都有个缺点，就是不受 kubelet 管理了，默认的 hosts 内容也会被覆盖掉在 k8s 环境下有更好的解决方案：那就是让 k8s 自己来管理使用 hostAliases 来绑定 hosts12345678910111213141516171819202122232425apiVersion: apps/v1kind: Deploymentmetadata: name: logstash-k8s namespace: opsspec: replicas: 1 selector: matchLabels: app: logstash-k8s template: metadata: labels: ...

找出占用Kubernetes节点磁盘的Pod

有部分开发不规范导致日志写入容器, 在 k8s 环境下导致节点磁盘空间占用过高, 解决方案有: 通过监控告警来提前预防挂载磁盘, 容器日志写入磁盘使用自动清理脚本 kubectl 查询每个 pod 占用磁盘空间1kubectl get --raw /api/v1/nodes/10.20.20.12/proxy/stats/summary | jq '.pods[] | "PodName: \(.podRef.name)", "usedBytes: \(.containers[].rootfs.usedBytes)", "======================================================"' 输出结果如图: Docker 相关操作查看容器磁盘占用12345# 节点上查看磁盘使用情况,并安装从大到小排序,可以看到各个容器的占用磁盘空间。docker ps -a --format "table {{.Size}...

Kubernetes回滚应用之kubectl rollout

kubernetes 每次更新资源会记录资源的历史版本，方便我们进行回滚操作。真的 k8s 解决了很多运维的痛点问题, 想起来以前没有用 k8s 的时候,用 jenkins 和 ansible 来做的发布和回滚… 查看历史版本12345678kubectl rollout history deployment nfs-client-provisionerdeployment.apps/nfs-client-provisionerREVISION CHANGE-CAUSE1 <none>2 <none>4 <none>5 <none> 这里列出的就是版本，为什么没有 3，因为从版本 4 回滚到了版本 3，则版本 3 就变成了版本 5 查看指定版本详情1kubectl rollout history deployment nfs-client-provisioner --revision=4 回滚到指定版本1kubectl rollout undo dep...

Kubernetes使用ingress反向代理外部IP

我们平常使用 k8s 的 service 都是自动发现增加 endpoint 的，但是有的时候集群外的服务我们又想用 k8s 的 ingress 来统一做入口，就会涉及到自定义 endpoint 创建 service123456789101112apiVersion: v1kind: Servicemetadata: name: kibana namespace: opsspec: type: ClusterIP ports: - name: kibana port: 80 protocol: TCP targetPort: 80 创建 endpoint12345678910111213apiVersion: v1kind: Endpointsmetadata: name: kibana namespace: opssubsets:- addresses: - ip: 10.0.0.12 - ip: 10.0.0.13 ports: - name: kibana port: 5601 protocol: TCP 创建 Ing...

Kubernetes中使用Prometheus对集群节点做监控

正常情况下使用 Prometheus 对机器做监控，比如监控 CPU、内存、磁盘等信息，都是在机器上安装一个 node exporter，然后将 metrics 接入到 Prometheus 中。在 k8s 环境下，我们可以使用 k8s 来管理，实现自动化监控。 node exporter 是针对主机节点的，需要在每台 node 节点上安装，那么 daemonset 控制器是最合理的选择。网络使用 Host Network 模式，在主机上直接暴露一个端口。部署 node exporter使用 yaml 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263apiVersion: apps/v1kind: DaemonSetmetadata: name: node-exporter namespace: monitor labels: name: node-exporters...

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 在文件最后添加 123stream { include stream.conf;} 然后 vim /etc/nginx/stream.conf ...

评论

数据加载中