Kubernetes 提供了 Secret 对象用于承载少量的机密/敏感数据，在实际使用中，有几种常规或者非常规的方式能够获取到 Secret 的内容：
HashiCorp Vault 是一个基于身份的 Secret 和加密管理系统。Secret 是您想要严格控制访问的内容，例如 API 加密密钥、密码或证书。Vault 提供由身份验证和授权方法控制的加密服务。使用 Vault 的 UI、CLI 或 HTTP API，可以安全地存储和管理对机密和其他敏感数据的访问、严格控制和可审计。
目前公司内部网站、项目比较多，运维的密钥管理主要都是靠个人保存，其中包含数据库密钥信息、申请的TLS证书、AWS密钥信息、各管理平台的密钥等，管理混乱，容易丢失，希望有一个平台能统一收集管理、签发、授权、审计。
将vault的helm repo克隆到本地，并checkout到最新版本v0.18.0：
很多时候我们可能都是直接将应用程序的密码或者 API Token 之类的私密信息直接暴露在源代码中的，显然直接暴露这些私密信息不是一个好的方式。在 Kubernetes 系统中提供了一个 Secret 对象来存储私密的数据，但是也只是简单的做了一次 Base64 编码而已，虽然比直接暴露要好点了，但是如果是一些安全性要求非常高的应用直接用 Secret 显然也还是不够的。本文就将来介绍如何使用 HashiCorp Vault 在 Kubernetes 集群中进行秘钥管理。
在 Kubernetes 中，我们通常会使用 Secret 对象来保存密码、证书等机密内容，然而 kubeadm 缺省部署的情况下，Secret 内容是用明文方式存储在 ETCD 数据库中的。能够轻松的用 etcdctl 工具获取到 Secret 的内容。通过修改 --encryption-provider-config 参数可以使用静态加密或者 KMS Server 的方式提高 Secret 数据的安全性，这种方式要求修改 API Server 的参数，在托管环境下可能没有那么方便，Hashicorp Vault 提供了一个变通的方式，用 Sidecar 把 Vault 中的内容加载成为业务容器中的文件。
Vault 是用于处理和加密整个基础架构秘钥的中心管理服务。Vault 通过 secret 引擎管理所有的秘钥，Vault 有一套 secret 引擎可以使用。
Apache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能的 API 网关，目前已经是 Apache 的顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。
云原生应用通常是由一组运行在容器中的分布式微服务架构起来的。目前越来越多的容器应用都是基于 Kubernetes 的，Kubernetes 已经成为了容器编排的事实标准。
本公众号分享的软件服务以及语言均源于网络，只做针对这些软件服务或者语言的使用实践进行分享和整理。本公众号不对任何人进行推荐，在使用这些软件或编程代码时有可能会引发一些问题，甚至导致数据丢失，请您自行承担相应的后果！本公众号概不负责! 若您觉得公众号发布的内容若侵犯到您的权益，请联系及时管理员沟通！
在多 Kubernetes 集群环境中，采用泛域名证书管理是一种有效策略。通过申请一个泛域名证书，你能够为同一根域名下的多个子域名提供安全的通信。使用泛域名证书（Wildcard Certificate）和 HashiCorp Vault 对于在多个 Kubernetes 集群中有效地管理证书是一个有效的策略。
根据 gartner 的调查报告 https://www.gartner.com/smarterwithgartner/gartner-top-9-security-and-risk-trends-for-2020 可以看到云原生安全仍然是2020年的一个大的趋势，同时，我们也看到许多安全创业公司已经留下了自己的足迹，在 KubeCon 2020 中，安全也是云计算应用的热门话题。
Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。
Helm 作为 Kubernetes 的包管理工具和 CNCF 毕业项目，在业界被广泛使用。但在实际使用场景中的一些需求 helm 并不能很好的满足，需要进行一些修改和适配，如同时部署多个 chart、不同部署环境的区分以及 chart 的版本控制。Helmfile 就是一个能够很好解决这些问题的小工具。
随着微服务架构的日益流行，企业正面临着构建高可用、可扩展且安全的微服务系统的挑战。在这种背景下，本方案提出了一种基于 APISIX 网关和 K3S 集群的微服务部署策略。这种策略不仅提高了系统的可用性和伸缩性，还简化了服务的发现和路由管理。
In the previous post Manage ONAP Microservices with Istio Service Mesh, we went through the steps of how to install Istio and integrate it with ONAP platform, it’s super simple and has nearly no impact to the existing projects. Now let’s enable Istio auth to secure the inter-service communication inside ONAP, it will need a little bit more efforts, but it’s worth with the benefits brought by it.
Kubernetes 已经毫无争议的成为了云原生时代的事实标准，在 Kubernetes 上部署应用程序也变得简单起来（无论是采用 kustomize 还是 helm），虽然对于敏感信息（比如用户名、密码、token 和证书等）的处理，Kubernetes 自己提供了 secret 这种方式，但是其是一种编码方式，而非加密方式，如果需要用版本控制系统（比如 git）来对所有的文件、内容等进行版本控制时，这种用编码来处理敏感信息的方式就显得很不安全了（即使是采用私有库），这一点在实现 GitOps 时，是一个痛点。基于此，本文就介绍三种可以加密 Kubernetes secret 的几种方式：Sealed Secrets、Helm Secrets 和 Kamus。
本文主要实现将AKS cluster上某个pod的日志转发汇总到ACH Hub端，并在ACM Hub端定义相应的alert rule，如果在Hub端检测到相应错误日志，触发alert，用户能及时知道远端AKS集群某个服务出现问题。
我们希望借助本文，让读者了解到如何在 Kubernetes 中使用可信镜像，其中依赖两个著名的 CNCF 开源项目：Notary 和 OPA。主要思路是使用 OPA 策略来定义自己的内容限制策略。
本文从实践角度介绍如何结合我们常用的 Gitlab 与 Jenkins，通过 K8s 来实现项目的自动化部署，示例将包括基于 SpringBoot 的服务端项目与基于 Vue.js 的 Web 项目。
详细安装过程见：https://kubernetes.github.io/ingress-nginx/deploy/
在上一篇文章中我们介绍安装了chartmuseum和helmpush，两者用来作为chart repo和chart repo的推送工具。这里我们主要介绍使用helm来发布更新以及回滚k8s应用，我们还是以之前文章中介绍的nginx application为例，使用helm来完成发布更新和回滚操作。
In the previous post How service mesh can help during the ONAP Microservice journey, we have discussed why the community wants ONAP to evolve towards Microservice architecture and how service mesh approach could help during the journey. Now it’s time to dip our toe in the water, let’s try out Istio with ONAP by following the below steps.
•（易于）发布（以网站域名的形式发布容器服务）•（易于）加固 (HTTPS + 认证）
在现代云原生应用部署和管理中，Helm 和 Helmfile 作为 Kubernetes 的包管理工具，扮演着至关重要的角色。为了提升部署效率和应用的可维护性，我们提出了 App 通用 Chart 包设计方案。本文将详细解释设计原则、设计目标以及如何使用我们的通用 Chart 包来简化应用部署流程。
用过minikube, VM启动比较慢, 而且下载最新版的时候, 阿里云的mirror都没有最新版本的镜像, 导致一直启动不起来. 非常难受.
Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程，方便开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），以便于满足 IT 需求规范，赋能 DevOps 团队。
之前写的Spinnaker自动化部署，部署复杂，依赖环境多，所以才有这一篇比较轻量级的自动化持续集成，需要用到的环境有Kubernetes-1.23、harbor、Jenkins、Helm、gitlab都是devops常见组件。
让我们在 Kubernetes 上创建一个CI/CD（持续集成和持续部署）解决方案，使用 Jenkins 作为构建工具，并使用 Traefik 作为用于灵活应用程序部署和路由的入口。
由于目前TKE已经集成了helm，用户只需在控制台点击安装便会下发tiller、swift
作者 | Eric Fossas 译者 | 刘雅梦 策划 | Tina 在生产中使用了 Istio 近两年之后，我们要和它说再见了。 服务网络大战正在肆虐。现在我把票投给了 Linkerd。 服务网格提供了微服务之间的流量监控，包括服务通信的映射和在它们之间生成的 HTTP 状态码。通过添加服务网格，你可以在服务间添加 mTLS，或者换句话说，可以在服务间添加加密的 HTTP 通信。 在我看来，这两个工具几乎对所有人都很有用。许多服务网格都提供了诸如流量分割、重试、超时等高级功能。我很少相信这些功能是有用的
[TOC] 0x00 前言简述 InfluxDB 介绍 Q: 什么是InfluxDB? InfluxDB 采用Go语言开发是一个开源时间序列平台, 是一个可编程且高性能的时间序列数据库，具有跨 OS
嗨，在当今动态的环境中，在 450 多家经过 Kubernetes 认证的服务提供商和众多经过 Kubernetes 认证的发行版中进行导航可能是一项艰巨的挑战。本博客旨在通过展示精心整理的2023 年最常用和最流行的 Kubernetes 工具列表来简化此过程。
前面我们学习了在 Kubernetes 集群内部使用 kube-dns 实现服务发现的功能，那么我们部署在 Kubernetes 集群中的应用如何暴露给外部的用户使用呢？我们知道可以使用 NodePort 和 LoadBlancer 类型的 Service 可以把应用暴露给外部用户使用，除此之外，Kubernetes 还为我们提供了一个非常重要的资源对象可以用来暴露服务给外部用户，那就是 Ingress。对于小规模的应用我们使用 NodePort 或许能够满足我们的需求，但是当你的应用越来越多的时候，你就会发现对于 NodePort 的管理就非常麻烦了，这个时候使用 Ingress 就非常方便了，可以避免管理大量的端口。
本教程已加入 Istio 系列：https://istio.whuanle.cn
尽管复杂，Kubernetes 仍然是目前最流行的编排器，但 HashiCorp 在 Nomad 上的成功也表明，Kubernetes 的替代方案还有发展空间。
如果用cfssl或者openssl之类的工具手动生成TLS证书，这样就可以轻松搞定站点的https访问了。理想是很美好，但实际操作时却很痛苦，主要有以下几点缺陷：
什么是 HTTPS 超文本传输协议 HTTP 协议被用于在 Web 浏览器和网站服务器之间传递信息，HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP 协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
说明 如果用cfssl或者openssl之类的工具手动生成TLS证书，这样就可以轻松搞定站点的https访问了。理想是很美好，但实际操作时却很痛苦，主要有以下几点缺陷：
DNS 服务是 Kubernetes 内置的服务发现组件，它方便容器服务可以通过发布的唯一 App 名字找到对方的端口服务，再也不需要维护服务对应的 IP 关系。这个对传统企业内部的运维习惯也是有一些变革的。一般传统企业内部都会维护一套 CMDB 系统，专门来维护服务器和 IP 地址的对应关系，方便规划管理好应用服务集群。当落地 K8s 集群之后，因为应用容器的 IP 生命周期短暂，通过 App 名字来识别服务其实对运维和开发都会更方便。所以本篇就是结合实际的需求场景给大家详细介绍 DNS 的使用实践。
作者简介：赵鑫，北京邮电大学19级硕士在读。从事Cassandra数据库的搭建和调优，目前为中国联通网络技术研究院云计算实习生，主要从事k8s和rancher相关平台的研究和技术调研。
前几天写过一篇k8s加入TLS安全访问，其中说到用cfssl之类的工具手动生成TLS证书，这样就可以轻松搞定站点的https访问了。理想是很美好，但实际操作时却很痛苦，主要有以下几点缺陷：
Linkerd 的自动 mTLS 功能使用一组 TLS 凭据(TLS credentials)为代理生成 TLS 证书(TLS certificates)：信任锚(trust anchor)、颁发者证书(issuer certificate)和私钥(private key)。虽然 Linkerd 每 24 小时自动轮换数据平面代理的 TLS 证书， 但它不会轮换用于颁发这些证书的 TLS 凭据。在本文档中，我们将描述如何使用外部解决方案 自动轮换颁发者证书和私钥。
常规的做法是给集群资源预留保障集群可用，通常20%左右。这种方式看似没什么问题，但放到Kubernetes中，就会发现如下2个问题。
这个博客最初是由Ayrat Khayretdinov在CloudOps博客上发布
Rancher简介 Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器。 Rancher可以轻松地管理各种环境的Kubernetes，满足IT需求并为DevOps团队提供支持。 Kubernetes不仅已经成为的容器编排标准，它也正在迅速成为各类云和虚拟化厂商提供的标准基础架构。Rancher用户可以选择使用Rancher Kubernetes Engine(RKE)创建Kubernetes集群，也可以使用GKE，AKS和EKS等云Kubernetes服务。 Rancher用户还可以导入和管理现有的Kubernetes集群。 Rancher支持各类集中式身份验证系统来管理Kubernetes集群。例如，大型企业的员工可以使用其公司Active Directory凭证访问GKE中的Kubernetes集群。IT管理员可以在用户，组，项目，集群和云中设置访问控制和安全策略。 IT管理员可以在单个页面对所有Kubernetes集群的健康状况和容量进行监控。 Rancher为DevOps工程师提供了一个直观的用户界面来管理他们的服务容器，用户不需要深入了解Kubernetes概念就可以开始使用Rancher。 Rancher包含应用商店，支持一键式部署Helm和Compose模板。Rancher通过各种云、本地生态系统产品认证，其中包括安全工具，监控系统，容器仓库以及存储和网络驱动程序。下图说明了Rancher在IT和DevOps组织中扮演的角色。每个团队都会在他们选择的公共云或私有云上部署应用程序。
基于 centos7.9，docker-ce-20.10.18，kubelet-1.22.3-0， traefik-2.9.10
Istio 是 Service Mesh（服务网格）的主流实现方案。该方案降低了与微服务架构相关的复杂性，并提供了负载均衡、服务发现、流量管理、断路器、监控、故障注入和智能路由等功能特性。
下图来自rancher官方博客，在kubernetes环境下，jenkins任务被交给各个pod执行，这些pod在需要时被创建，任务结束后被销毁，这样既能合理利用资源，又能给每个任务提供一致的干净的初始化环境（也可以保留pod，如查问题的时候）
说到istio就要先说什么是ServiceMesh，从英文直译过来就就叫做“服务网格”，这个技术大概是在10多年前就被提出来的，但是最近2年被炒的异常火热。那什么叫做ServiceMesh呢？看下图：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
