3 8
Kubernetes CRD 开发实践

背景

Kubernetes的最大亮点之一必定是它的声明式API设计,所谓的声明式就是告诉kubernetes你要什么,而不是告诉它怎么做命令。我们日常使用kubernetes做编排工作的时候,经常会接触 DeploymentServicePod 等资源对象,我们可以很灵活地创建其定义配置,然后执行 kubectl apply 命令,kubernetes总能为我们创建相关资源对象并完成资源的注册,进而执行资源所负责的功能。

但是我们有没想过,日常业务开发过程中,虽然常规的资源基本满足需求,但是这些常规的资源大多仅仅是代表相对底层、通用的概念的对象, 某些情况下我们总是想根据业务定制我们的资源类型,并且利用kubernetes的声明式API,对资源的增删改查进行监听并作出具体的业务功能。随着Kubernetes生态系统的持续发展,越来越多高层次的对象将会不断涌现,比起目前使用的对象,新对象将更加专业化。

有了自定义资源定义API,开发者将不需要逐一进行 Deployment、Service、ConfigMap 等步骤,而是创建并关联一些用于表述整个应用程序或者软件服务的对象。除此,我们能使用自定义的高阶对象,并在这些高阶对象的基础上创建底层对象。例如:我们想要一个Backup资源,我们创建它的对象时,就希望通过spec的定义进行日常的备份操作声明,当提交给k8s集群的时候,相关的Deployment、Service资源会被自动创建,很大程度让业务扩展性加大。

3 6
Kubernetes部署本地有状态mysql主从服务

一般情况下Kubernetes可以通过ReplicaSet以一个Pod模板创建多个pod副本,但是它们都是无状态的,任何时候它们都可以被一个全新的pod替换。然而有状态的pod需要另外的方案确保当一个有状态的pod挂掉后,这个pod实例需要在别的节点上重建,但是新的实例必须与被替换的实例拥有相同的名称、网络标识和状态。这就是Statefulset管理pod的手段。

对于容器集群,有状态服务的挑战在于,通常集群中的任何节点都并非100%可靠的,服务所需的资源也会动态地更新改变。当节点由于故障或服务由于需要更多的资源而无法继续运行在原有节点上时,集群管理系统会为该服务重新分配一个新的运行位置,从而确保从整体上看,集群对外的服务不会中断。若采用本地存储,当服务漂移后数据并不会随着服务转移到新的节点,重启服务就会出现数据丢失的困境。

本文目的是通过一个mysql的主从集群搭建,深入了解kubernetes的statfulset管理。为了降低实验的外部依赖,存储层面上,我采用的是本地存储,当然生产上不建议这样做,生产环境的存储推荐官方介绍到的的gce、nfs、ceph等存储方案,因为这些方案支持动态供给的特性,允许开发人员通过pvc的定义,快速实现数据有效存储,所以你绝不应该把一个宿主机上的目录当作 PV 使用, 只是本文用于实验需要,采用Local Persistent Volume的手段,目的只是为了验证Statefulset的状态管理功能。

实验环境

  • kubernetes Master
  • kubernetes Node (测试演示,所有的副本都会在其上运行)
  • kubernetes DNS服务已开启

实验目的

  • 搭建一个主从复制(Master-Slave)的MySQL 集群
  • 从节点可以水平扩展
  • 所有的写操作只能在主节点上执行
  • 读操作可以在主从节点上执行
  • 从节点能同步主节点的数据
12 16
部署Kubernetes PostgreSQL实例

本文主要演示如何通过Kubernetes提供的持久化卷(PV)和Statefulset来部署Pg数据库容器。所以本文假设您已经搭建了K8S的运行环境,你也可以使用minikube来安装搭建k8s环境。

镜像准备

我们打算使用官方提供的Postgresql 12.1:https://hub.docker.com/_/postgres 版本的镜像作为我们的部署镜像,这个版本的镜像提供了齐全的功能,并且支持我们使用编排文件配置环境变量,如用户名、密码、默认数据库、pgdata路径等。

下面我们可以正式开始实例的演示了… …

10 4
UNIX编程设计原则

Unix诞生与1969年,可一个可以改变21世纪甚至更远的未来的操作系统问世,至少现在的Linux是基于Unix的设计哲学。unix汇聚了很多黑客的智慧,他是一个开放,自由,KISS,单一的系统。

下面原则整理自《Unix编程艺术》

1.模块原则

使用简洁的接口拼合简单的部件。

2.清晰原则

清晰胜于技巧。

3.组合原则

设计时考虑拼接组合,在输入输出方面,Unix极力提倡采用简单、文本化、面向流、设备无关的格式。因此一般在Unix下多数程序都尽可能采用简单过滤器的形式,将一个输入的简单文本流处理为一个简单的文本流输出。

4.分离原则

策略同机制分离,接口同引擎分离。

5.简洁原则

设计要简洁,复杂度能低则低。

6.吝啬原则

除非确无他法,不要编写庞大的程序。

7.透明性原则

设计要可见,以便审查和调试。要一眼就能看出软件是在做什么以及怎样做的。显见性指程序带有监视和显示内部状态的功能。

8.健壮原则

健壮源于透明和简洁。

9.表示原则

复杂的数据,尽量用数组初始化表示,不要把复杂的选择逻辑丢进程序里。

10.通俗原则

接口设计避免标新立异。越通俗,越流行,越好。

11.缄默原则

即程序只做该做的事,不做多余的事,默默工作

12.补救原则

出现异常时,马上退出并给出足够错误信息。

13.经济原则

宁花机器一分,不花程序员一秒。

14.生成原则

避免手工hack,尽量编写程序去生成程序。

15.优化原则

优化之前先确保能用。先求运行,再求正确,最后求快。

16.多样原则

按我的理解,就是兼容性强,广泛采取多种语言、开放的可扩展系统和用户定制机制。

17.扩展原则

设计着眼未来,未来总比预想来得快。

一言以蔽之:K.I.S.S Keep It Simple,Stupid!

后一页