建设银行官方网站首页个人登录,dw网站制作的源代码,外贸流程英语,wordpress指定目录为首页摘要#xff1a; 在容器服务的客户群中#xff0c;一个经常被问起的问题就是如何处理服务间依赖。本文介绍了常见的解决方法来实现服务的依赖检查#xff0c;还进一步用示例展示了如何利用init container#xff0c; liveness/readiness探针等技术实现服务健康检查#xf…摘要 在容器服务的客户群中一个经常被问起的问题就是如何处理服务间依赖。本文介绍了常见的解决方法来实现服务的依赖检查还进一步用示例展示了如何利用init container liveness/readiness探针等技术实现服务健康检查依赖检查等等功能。
本系列文章记录了企业客户在应用Kubernetes时的一些常见问题第一篇Java应用资源限制的迷思第二篇利用LXCFS提升容器资源可见性第三篇解决服务依赖在容器服务的客户群中一个经常被问起的问题就是如何处理服务间依赖。在应用中一个组件依赖指定的中间件服务和业务服务。在传统的软件部署方式中应用启动、停止都要依照特定的顺序完成。当采用 Kubernetes/Docker Swarm等容器编排技术在分布式环境下部署应用时一方面不同组件之间并行启动无法保证其启动顺序另一方面在应用运行时其所依赖的服务实现有可能发生失败和迁移。如何解决容器之间的服务依赖就是一个非常常见的问题。方法1 - 应用端服务依赖检查我们可以在应用的启动逻辑中添加服务依赖检查逻辑如果应用依赖的服务不可访问就重试当错误超过一定次数后就自动退出。Kubernetes/Docker会根据所容器的重启策略(Restart Policy)在等待一段时间之后自动拉起。下面就是一个简单的Golang应用示例来检测所依赖的MySQL服务是否就绪。 ...// Connect to database.hostPort : net.JoinHostPort(config.Host, config.Port)log.Println(Connecting to database at, hostPort)dsn : fmt.Sprintf(%s:%stcp(%s)/%s?timeout30s,config.Username, config.Password, hostPort, config.Database)db, err sql.Open(mysql, dsn)if err ! nil {log.Println(err)}var dbError errormaxAttempts : 20for attempts : 1; attempts maxAttempts; attempts {dbError db.Ping()if dbError nil {break}log.Println(dbError)time.Sleep(time.Duration(attempts) * time.Second)}if dbError ! nil {log.Fatal(dbError)}log.Println(Application started successfully.)...
注 Fail Fast (快速失败)是Design by Contract契约式设计的一种重要的原则可以很好地保障系统的健壮性和可预测性。比如上文代码中如果重试失败就会由log.Fatal(dbError) 退出执行。而K8S/Docker的容器重启的回退机制可以保障不会因频繁拉起失败应用导致系统资源耗尽。方法2 - 独立的服务依赖检查逻辑在现实世界里有些遗留应用或者框架无法进行调整。我们就会希望将依赖检查策略和应用逻辑进行解耦。一个常见的方法是在容器的Dockerfile的启动脚本里加入相应的服务依赖检查逻辑可以参见Docker文档获得更多信息。另一种方法是利用Kubernetes Pod自身机制添加依赖检查逻辑。首先我们需要对Pod的生命周期有一定的理解下图来自于 https://blog.openshift.com/kubernetes-pods-life/ 一文首先在Pod中有三类容器infra container: 这就是著名的pause容器init container: 初始化容器 通常用于应用的初始化准备只有等所有的初始化容器正常执行完毕之后才会启动应用容器main container: 应用容器Kubernetes的最佳实践中通常是利用初始化容器来进行依赖服务的检查。下面我们通过一个Wordpress的实例来展示其使用方法。apiVersion: v1
kind: Service
metadata:name: mysql
spec:clusterIP: Noneports:- name: mysqlport: 3306selector:app: mysql
---
apiVersion: v1
kind: Service
metadata:name: wordpress
spec:ports:- name: wordpressport: 80targetPort: 80selector:app: wordpresstype: NodePort
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:selector:matchLabels:app: mysqlserviceName: mysql replicas: 1template:metadata:labels:app: mysqlspec:containers:- name: mysqlimage: mysql:5.7env:- name: MYSQL_ALLOW_EMPTY_PASSWORDvalue: truelivenessProbe:exec:command: [mysqladmin, ping]initialDelaySeconds: 30periodSeconds: 10timeoutSeconds: 5readinessProbe:exec:# Check we can execute queries over TCP (skip-networking is off).command: [mysql, -h, 127.0.0.1, -e, SELECT 1]initialDelaySeconds: 5periodSeconds: 2timeoutSeconds: 1
---
apiVersion: apps/v1
kind: Deployment
metadata:name: wordpress
spec:replicas: 1selector:matchLabels:app: wordpresstemplate:metadata:labels:app: wordpressspec:containers:- name: wordpressimage: wordpress:4ports:- containerPort: 80env:- name: WORDPRESS_DB_HOSTvalue: mysql- name: WORDPRESS_DB_PASSWORDvalue: initContainers:- name: init-mysqlimage: busyboxcommand: [sh, -c, until nslookup mysql; do echo waiting for mysql; sleep 2; done;]我们在Wordpress Deployment的Pod定义中添加了initContainers它会通过检查 mysql 域名是否可以解析来判断所依赖的mysql服务是否就绪。同时在MySQL StatefulSet中我们也引入了readinessProbe 和 livenessProbe探针它们会判定是否MySQL进程已经业务就绪。在K8S中只有健康的Pod才可以通过ClusterIP访问或者DNS解析。$ kubectl create -f wordpress.yaml
service mysql created
service wordpress created
statefulset mysql created
deployment wordpress created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 0/1 Running 0 5s
wordpress-797655cf44-w4p87 0/1 Init:0/1 0 5s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 11s
wordpress-797655cf44-w4p87 0/1 Init:0/1 0 11s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 14s
wordpress-797655cf44-w4p87 0/1 PodInitializing 0 14s
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-0 1/1 Running 0 17s
wordpress-797655cf44-w4p87 1/1 Running 0 17s
$ kubectl describe pods wordpress-797655cf44-w4p87
...注Liveness探针主要用于判断Container是否处于运行状态比如当服务死锁或者响应缓慢等情况。Readiness探针主要用于判断服务是否已经正常工作。在init container中不允许使用readiness探针。如果Pod重启了其所有init Container都需重新运行。总结本文介绍了常见的解决方法来实现服务的依赖检查还进一步用示例展示了如何利用init container liveness/readiness探针等技术实现服务健康检查依赖检查等等功能。Kubernetes提供了非常灵活的Pod生命周期管理机制由于篇幅有限我们就不再展开介绍 postStart/preStop等生命周期钩子方法。阿里云Kubernetes服务 全球首批通过Kubernetes一致性认证简化了Kubernetes集群生命周期管理内置了与阿里云产品集成也将进一步简化Kubernetes的开发者体验帮助用户关注云端应用价值创新。原文链接干货好文请关注扫描以下二维码
