使用base64生成kubernetes使用的secret yaml

发表于2022-11-04|更新于2024-10-31|容器

|浏览量:

先申请证书, 证书申请下来后会有证书 (一般都是 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中使用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:...

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 内存快照。：...

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

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

Kubernetes创建一个只读用户

其实用到的是 RBAC 授权，官方文档在：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/ 生成证书12345678# 生成私钥openssl genrsa -out dev.key 2048# 基于这个私钥生成证书请求openssl req -new -key dev.key -out dev.csr -subj "/CN=dev"# 使用CA证书签发openssl x509 -req -in dev.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dev.crt -days 3000 通过证书生成 kubeconfig 配置文件12345678910111213141516171819202122232425262728# 生成用户kubeconfigkubectl config set-cluster kubernetes \ ...

评论

数据加载中