Helm Chart 模板开发技巧

Helm Chart 在我们使用的时候非常方便的,但是对于开发人员来说 Helm Chart 模板就并不一定显得那么友好了,本文主要介绍了 Helm Chart 模板开发人员在构建生产级的 Chart 包时的一些技巧和窍门。

[阅读全文]

Kubernetes 网络故障常见排查方法

troubleshooting kubernetes 网络可以说是 Kubernetes 部署和使用过程中最容易出问题的了,最主要的是对网络技术非常熟悉的人员相对较少,和 Kubernetes 结合后能搞透彻网络这块的就更加稀少了,导致我们在部署使用过程中经常遇到一些网络问题。本文将重点关注网络,列出我们遇到的一些问题,包括解决和发现问题的简单方法,并就如何避免这些故障提供一些建议。

[阅读全文]

nginx-ingress 的安装使用

nginx-ingress 和 traefik 都是比如热门的 ingress-controller,作为反向代理将外部流量导入集群内部,将 Kubernetes 内部的 Service 暴露给外部,在 Ingress 对象中通过域名匹配 Service,这样就可以直接通过域名访问到集群内部的服务了。相对于 traefik 来说,nginx-ingress 性能更加优秀,但是配置比 traefik 要稍微复杂一点,当然功能也要强大一些,支持的功能多许多,前面我们为大家介绍了 traefik 的使用,今天为大家介绍下 nginx-ingress 在 Kubernetes 中的安装使用。

[阅读全文]

如何保护对外暴露的 Kubernetes 服务

有时候我们需要在 Kubernetes 中暴露一些没有任何安全验证机制的服务,比如没有安装 xpack 的 Kibana,没有开启登录认证的 Jenkins 服务之类的,我们也想通过域名来进行访问,比较域名比较方便,更主要的是对于 Kubernetes 里面的服务,通过 Ingress 暴露一个服务太方便了,而且还可以通过 cert-manager 来自动的完成HTTPS化。所以就非常有必要对这些服务进行一些安全验证了。

[阅读全文]

基于 Jenkins、Gitlab、Harbor、Helm 和 Kubernetes 的 CI/CD(一)

上节课和大家介绍了Gitlab CI结合Kubernetes进行 CI/CD 的完整过程。这节课结合前面所学的知识点给大家介绍一个完整的示例:使用 Jenkins + Gitlab + Harbor + Helm + Kubernetes 来实现一个完整的 CI/CD 流水线作业。

其实前面的课程中我们就已经学习了 Jenkins Pipeline 与 Kubernetes 的完美结合,我们利用 Kubernetes 来动态运行 Jenkins 的 Slave 节点,可以和好的来解决传统的 Jenkins Slave 浪费大量资源的缺点。之前的示例中我们是将项目放置在 Github 仓库上的,将 Docker 镜像推送到了 Docker Hub,这节课我们来结合我们前面学习的知识点来综合运用下,使用 Jenkins、Gitlab、Harbor、Helm、Kubernetes 来实现一个完整的持续集成和持续部署的流水线作业。

[阅读全文]

在 Kubernetes 上安装 Gitlab

gitlab on k8s

Gitlab官方提供了 Helm 的方式在 Kubernetes 集群中来快速安装,但是在使用的过程中发现 Helm 提供的 Chart 包中有很多其他额外的配置,所以我们这里使用自定义的方式来安装,也就是自己来定义一些资源清单文件。

Gitlab主要涉及到3个应用:Redis、Postgresql、Gitlab 核心程序,实际上我们只要将这3个应用分别启动起来,然后加上对应的配置就可以很方便的安装 Gitlab 了,我们这里选择使用的镜像不是官方的,而是 Gitlab 容器化中使用非常多的一个第三方镜像:sameersbn/gitlab,基本上和官方保持同步更新,地址:http://www.damagehead.com/docker-gitlab/

[阅读全文]

Harbor 源码浅析

harbor

Harbor 是一个CNCF基金会托管的开源的可信的云原生docker registry项目,可以用于存储、签名、扫描镜像内容,Harbor 通过添加一些常用的功能如安全性、身份权限管理等来扩展 docker registry 项目,此外还支持在 registry 之间复制镜像,还提供更加高级的安全功能,如用户管理、访问控制和活动审计等,在新版本中还添加了Helm仓库托管的支持。

[阅读全文]

Kubernetes 部署策略详解

Kubernetes中有几种不同的方式发布应用,所以为了让应用在升级期间依然平稳提供服务,选择一个正确的发布策略就非常重要了。

选择正确的部署策略是要依赖于我们的业务需求的,下面我们列出了一些可能会使用到的策略:

  • 重建(recreate):停止旧版本部署新版本

  • 滚动更新(rolling-update):一个接一个地以滚动更新方式发布新版本

  • 蓝绿(blue/green):新版本与旧版本一起存在,然后切换流量

  • 金丝雀(canary):将新版本面向一部分用户发布,然后继续全量发布

  • A/B测(a/b testing):以精确的方式(HTTP 头、cookie、权重等)向部分用户发布新版本。A/B测实际上是一种基于数据统计做出业务决策的技术。在 Kubernetes 中并不原生支持,需要额外的一些高级组件来完成改设置(比如Istio、Linkerd、Traefik、或者自定义 Nginx/Haproxy 等)。

[阅读全文]

Istio 实训免费视频课程

istio

Istio,是一个由 Google,Lyft,IBM 联合开发的开源项目,是服务网格(Service Mesh)技术的一个标准化的开源实现,致力于解决应用的微服务化组件之间的连接控制与安全、流量管理与可观测性。Istio 是云原生领域在 Kubernetes 之后最受关注的项目,帮助容器技术实践者从基础设施层的“容器编排“进阶到应用层的“服务治理”。Istio 先天与 Kubernetes 无缝衔接,了解并使用 Istio 可以极大地提升研发和运维的工作效率。

[阅读全文]