Clarification of software architecture, namely pluginDaemon

[BorisPolonsky]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• Please do not modify this template :) and fill in all the required fields.

Provide a description of requested docs changes

We are the developers of dify-helm. While migrating pluginDaemon to kubernetes but there's no clue on software design from the current documentation. We need clarification on the following topics

Is this component is stateless (e.g. support multi-replica deployment) given the current version of the document.

We would like to know if it's appropriate to declare this component as Deployment

dify/docker/docker-compose-template.yaml

Lines 141 to 161 in 28edbba

	# plugin daemon
	plugin_daemon:
	image: langgenius/dify-plugin-daemon:0.0.1-local
	restart: always
	environment:
	# Use the shared environment variables.
	<<: *shared-api-worker-env
	DB_DATABASE: ${DB_PLUGIN_DATABASE:-dify_plugin}
	SERVER_PORT: ${PLUGIN_DAEMON_PORT:-5002}
	SERVER_KEY: ${PLUGIN_DAEMON_KEY:-lYkiYYT6owG+71oLerGzA7GXCgOT++6ovaezWAjpCjf+Sjc3ZtU+qUEi}
	MAX_PLUGIN_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800}
	PPROF_ENABLED: ${PLUGIN_PPROF_ENABLED:-false}
	DIFY_INNER_API_URL: ${PLUGIN_DIFY_INNER_API_URL:-http://api:5001}
	DIFY_INNER_API_KEY: ${PLUGIN_DIFY_INNER_API_KEY:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1}
	PLUGIN_REMOTE_INSTALLING_HOST: ${PLUGIN_DEBUGGING_HOST:-0.0.0.0}
	PLUGIN_REMOTE_INSTALLING_PORT: ${PLUGIN_DEBUGGING_PORT:-5003}
	PLUGIN_WORKING_PATH: ${PLUGIN_WORKING_PATH:-/app/storage/cwd}
	ports:
	- "${EXPOSE_PLUGIN_DEBUGGING_PORT:-5003}:${PLUGIN_DEBUGGING_PORT:-5003}"
	volumes:
	- ./volumes/plugin_daemon:/app/storage

[BorisPolonsky]

I've noticed a log of plugin-daemon as below

2025/01/25 16:14:09 cluster_lifetime.go:113: [INFO]current node has become the master of the cluster

Does it means that roles of multiple plugin-daemon container are not identical and shall be defined as StatefulSets instead of Deployment?
@takatost

[kurokobo]

I’m just a contributor and not a member of the Dify team, but as far as I understand, the state of each plugin daemon container is all stored on Redis.
The voting and decision on which nodes will be the master node is made automatically using Redis, so I haven't tested it, but I think multi-replica is probably supported.

This is a repository of the plugin daemon: https://github.com/langgenius/dify-plugin-daemon
and here are some reference codes and comments for your concern: https://github.com/langgenius/dify-plugin-daemon/blob/fc3cba5f2c9e1dc71edc8d6e5eed5814bd149f0f/internal/cluster/cluster_lifetime.go#L11-L40

[BorisPolonsky]

I’m just a contributor and not a member of the Dify team, but as far as I understand, the state of each plugin daemon container is all stored on Redis. The voting and decision on which nodes will be the master node is made automatically using Redis, so I haven't tested it, but I think multi-replica is probably supported.

This is a repository of the plugin daemon: https://github.com/langgenius/dify-plugin-daemon and here are some reference codes and comments for your concern: https://github.com/langgenius/dify-plugin-daemon/blob/fc3cba5f2c9e1dc71edc8d6e5eed5814bd149f0f/internal/cluster/cluster_lifetime.go#L11-L40

Thanks for your hints. It appears to me that both node and master of pluginDaemon identify itself by IPv4 address. I'm still not sure if a stable network identifier (e.g. a stable network IP for each pod throughout the whole lifecycle of StatefulSets) or ordered deployment and termination is mandatory in this scenario.

[kurokobo]

I'm still not sure if a stable network identifier (e.g. a stable network IP for each pod throughout the whole lifecycle of StatefulSets) or ordered deployment and termination is mandatory in this scenario.

Hmm, I think it's unnecessary to have such delicate control over the state of the pod since it simply registers its own IP address to Redis every 5 seconds, and it becomes invalid if there are no updates for 10 seconds. Quite simple.

I believe that the Dify Team also needs to provide this daemon in a way that can withstand high loads in a SaaS model with HA (perhaps on Kubernetes), so I think they are steering away from architectures that require delicate control by design.

[BorisPolonsky]

Supported as Deployment. BorisPolonsky/dify-helm#123

[Winson-030]

I declared this component as a Deployment in the yaml file.
Winson-030/dify-kubernetes@8c4b6a0