使用base64生成kubernetes使用的secret yaml

发表于2022-11-04|更新于2026-06-08|容器

|浏览量:

先申请证书, 证书申请下来后会有证书 (一般都是 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中部署nacos 2.1.0

本次在 Kubernetes 上部署 nacos 2.1.0 版本，部署 3 节点集群，不做数据持久化（nacos 的配置管理是存储 MySQL 数据库的，服务发现是需要本地存储的）新版本 nacos 部署参考：在Kubernetes中部署nacos 2.3.2 MySQL 数据库准备创建数据库，配置好账号权限，执行如下 SQL 建表： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441...

kubernetes删除节点

删除 worker 节点设置节点不可调度，即不会有新的 pod 在该节点上创建 12kubectl cordon 172.16.21.26kubectl drain 172.16.21.26 --delete-local-data --ignore-daemonsets --force –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使用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...

使用cronjob自动重启k8s的deployment

配置权限1234567891011121314151617181920212223242526272829303132---kind: ServiceAccountapiVersion: v1metadata: name: deployment-restart namespace: default---apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: deployment-restart namespace: defaultrules: - apiGroups: ["apps", "extensions"] resources: ["deployments"] resourceNames: [] verbs: ["get", "patch", "list", "watch"] # list 和 watch 就够用了，如果需要执行 ro...

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

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

评论

数据加载中