Re:Re: Flink k8s HA 手动删除作业deployment导致的异常

2022-06-13 文章 m18814122325



感谢两位大大回复!














在 2022-06-13 10:09:39,"Yang Wang"  写道:
>Zhanghao的回答已经非常全面了,我再补充小点,删除Deployment保留HA ConfigMap是预期内的行为,文档里面有说明[1]
>之所以这样设计有两点原因:
>(1.) 任务可能会被重启,但使用相同的cluster-id,并且希望从之前的checkpoint恢复
>(2.) 单纯的删除ConfigMap会导致存储在DFS(e.g. HDFS、S3、OSS)上面的HA数据泄露
>
>[1].
>https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/ha/kubernetes_ha/#high-availability-data-clean-up
>
>
>Best,
>Yang
>
>Zhanghao Chen  于2022年6月13日周一 07:53写道:
>
>> 1.基于K8S做HA的Flink任务要想正常,不能手动删除作业deployment,必须通过cancel,stop命令进行停止。基于上面我猜测Flink
>> k8s HA是基于ConfigMap之上开发的,其声明周期从K8S角度不能像作业的svc一样带ownerreference。
>>
>> 是的,Flink K8s HA 是基于 ConfigMap 开发的,并且 HA configmap 没有设置
>> ownerreference,因此如果想在保留 HA 数据的情况下重启集群直接 delete deployment 就行,重启后会从最新 cp 恢复。
>>
>> 2.基于k8s做HA的Flink job id皆为。
>>
>> 开启 HA 的 Application mode 的 Flink job id
>> 皆为,与是否使用 K8s HA 无关。job id 是作业的唯一标识符,HA
>> 服务使用它来命名和寻址和单个作业有关的 HA 资源(如保存的 jobgraph 和 cp)。Application mode 下 jobgraph 在
>> JM 生成,不开启 HA 时每次生成 jobgraph 会随机生成一个 job id 作为 job 的 唯一标识符,开启 HA 时需要使用一个固定的
>> job id (一串 0 的 jobid 就是这么来的),否则 JM failover 后重新生成了一个新的不同的 job id,无法和之前的 cp
>> 相关联,导致作业从全新状态恢复。
>>
>> 3.Flink k8s HA 是如何工作的,其中存储了什么信息?我想学习其中相关实现,如果大家有其设计文档或相关资料,希望可以回此邮件告诉我,谢谢。
>>
>> 可以看下官方的博客文章: 
>> https://flink.apache.org/2021/02/10/native-k8s-with-ha.html,更多细节可以参阅
>> JIRA 设计文档:
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-144%3A+Native+Kubernetes+HA+for+Flink
>>
>>
>> Best,
>> Zhanghao Chen
>> 
>> From: m18814122325 
>> Sent: Sunday, June 12, 2022 22:45
>> To: user-zh@flink.apache.org 
>> Subject: Flink k8s HA 手动删除作业deployment导致的异常
>>
>> Flink version: 1.15.0
>>
>> deploy mode: Native k8s application
>>
>>
>>
>>
>> 问题现象:
>>
>> 我以Native
>> k8s模式部署了一个基于K8S做HA的Flink任务,当我手动删除了作业的deployment后,发现作业做HA的ConfigMap还存在。并且接下来不加参数-s
>> 再次启动作业,从启动日志发现其会从上述ConfigMap记录信息中恢复。
>>
>>
>>
>>
>> kubectl delete deployment flink-bdra-sql-application-job -n
>> bdra-dev-flink-standalone
>>
>>
>>
>>
>> kubectl get configMap -n bdra-dev-flink-standalone
>>
>>
>>
>>
>> NAME
>>DATA   AGE
>>
>> flink-bdra-sql-application-job--config-map
>> 2  13m
>>
>> flink-bdra-sql-application-job-cluster-config-map
>>   1  13m
>>
>>
>>
>>
>>
>>
>>
>> 我有以下疑问:
>>
>> 1.基于K8S做HA的Flink任务要想正常,不能手动删除作业deployment,必须通过cancel,stop命令进行停止。基于上面我猜测Flink
>> k8s HA是基于ConfigMap之上开发的,其声明周期从K8S角度不能像作业的svc一样带ownerreference。
>>
>> 2.基于k8s做HA的Flink job id皆为。
>>
>> 3.Flink k8s HA 是如何工作的,其中存储了什么信息?我想学习其中相关实现,如果大家有其设计文档或相关资料,希望可以回此邮件告诉我,谢谢。
>>
>>
>>
>>
>> 重启命令(不带-s参数,意味着命令本身不带任何从ck或者savepoint恢复)
>>
>> flink run-application --target kubernetes-application -c CalculateUv
>> -Dkubernetes.cluster-id=flink-bdra-sql-application-job-s3p
>> -Dkubernetes.container.image=
>> acpimagehub.cgb.cn/bdra_dev/flink-sql-s3:v0.20
>> -Dkubernetes.namespace=bdra-dev-flink-standalone
>> -Dkubernetes.service-account=bdra-dev-flink-standalone-sa
>> -Djobmanager.memory.process.size=1024m -Dkubernetes.jobmanager.cpu=2
>> -Dkubernetes.taskmanager.cpu=2 -Dparallelism.default=8
>> -Dtaskmanager.numberOfTaskSlots=2 -Dtaskmanager.memory.process.size=2144m
>> -Dstate.backend=filesystem
>> -Dstate.checkpoints.dir=s3p://bdra-user-lun01/flink-checkpoints/flink-bdra-sql-application-job-s3
>> -Dstate.savepoints.dir=s3a://bdra-user-lun01/flink-savepoints/flink-bdra-sql-application-job-s3
>> -Dhigh-availability=org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory
>> -Dhigh-availability.storageDir=file:///opt/flink/log/recovery
>> -Ds3.access-key=* -Ds3.secret-key=*
>> -Dmetrics.reporter.influxdb.factory.class=org.apache.flink.metrics.influxdb.InfluxdbReporterFactory
>> -Dmetrics.reporter.influxdb.scheme=http
>> -Dmetrics.reporter.influxdb.host=influxdb
>> -Dmetrics.reporter.influxdb.port=8086
>> -Dmetrics.reporter.influxdb.db=flink_metrics
>> -Dmetrics.reporter.influxdb.consistency=ANY -Ds3.endpoint=http://*:80
>> -Dkubernetes.rest-service.exposed.type=ClusterIP
>> -Dkubernetes.config.file=kube_config
>> -Dkubernetes.pod-template-file=pod-template.yaml
>> local:///opt/flink/usrlib/flink-sql-1.0-SNAPSHOT.jar
>>
>>
>>
>>
>> 重启后自动从ConfigMap中恢复。
>>
>> 2022-06-10 20:20:52,592 INFO
>> org.apache.flink.runtime.dispatcher.runner.SessionDispatcherLeaderProcess
>> [] - Successfully recovered 1 persisted job graphs.
>>
>> 2022-06-10 20:20:52,654 INFO
>> org.apache.flink.runtime.rpc.akka.AkkaRpcService [] - Starting
>> RPC endpoint for org.apache.flink.runtime.dispatcher.StandaloneDispatcher
>> at akka://flink/user/rpc/dispatcher_1 .
>>
>> 2022-06-10 20:20:53,552 INFO
>> org.apache.flink.kubernetes.KubernetesResourceManagerDriver  [] - Recovered
>> 0 pods from previous attempts, current attempt id is 1.
>>
>> 2022-06-10 20:20:53,552 INFO
>> org.apache.flink.runtime.resourcemanager.active.ActiveResourceManager [] -
>> 

Re:Re: flink k8s ha

2022-06-08 文章 json
恩,明白保留HA配置的意义了但感觉是不是有bug,看我的问题,重启报找不到 
/high-availability.storageDir/task/completedCheckpointe5c125ad20ea 
文件但oss上的HA目录只有 
/high-availability.storageDir/task/completedCheckpointacdfb4309903既HA的configmap
 信息和 high-availability.storageDir 目录里的文件不一致了
在 2022-06-08 23:06:03,"Weihua Hu"  写道:
>Hi,
>删除 deployment 会将关联到这个 Deployment 的 Pod、Service、flink-conf configmap 等删除。但是
>HA 相关的 configmap 没有配置 owner reference,是不会被删除的。主要目的是集群重启时可以从之前的HA
>状态中恢复。更多内容参考官方文档[1]
>
>[1]
>https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/ha/kubernetes_ha/#high-availability-data-clean-up
>Best,
>Weihua
>
>
>On Wed, Jun 8, 2022 at 4:24 PM json <18042304...@163.com> wrote:
>
>> configmap 如下
>> sql-test--jobmanager-leader
>> sql-test-resourcemanager-leader
>> sql-test-restserver-leader
>> sql-test-dispatcher-leader
>>
>>
>>
>> 在 2022-06-08 15:42:52,"json" <18042304...@163.com> 写道:
>>
>> flink1.13.6 on k8s application 模式,设置HA
>> high-availability:
>> org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory
>> high-availability.storageDir: oss
>> 会在 k8s 上生成configmap
>>
>>
>> 1. 但在 k8s 删除此任务的 deployment 后,为什么这些configmap还在?(任务都删了,这些ha应该不需要了吧)
>> 2. 任务重新启动后,还是会去这些 configmap 读ha配置,这个逻辑也很奇怪,任务重启,为什么要去读之前HA信息
>>
>> 为什么会关注这个,因为碰到一个问题:
>> 任务重启报错,找不到
>> /high-availability.storageDir/task/completedCheckpointe5c125ad20ea 文件,
>> 但oss 是有文件
>> /high-availability.storageDir/task/completedCheckpointe/completedCheckpointacdfb4309903
>> 导致我任务一直报错;删除 上面的configmap 才能正常运行
>>
>>
>>
>>
>>
>>