comment: add factory description

Signed-off-by: EunJiJung <[email protected]>

Author: bianbbc87

TROUBLESHOOTING_BLOG.md

@@ -72,6 +72,42 @@ type Agent struct {
 	connected atomic.Bool
 	// syncCh is not currently used
 	syncCh           chan bool
+	/**
+	 * STREAM/CONNECTION INTERFACE ABSTRACTION DESIGN
+	 * 
+	 * GOAL: Remove gRPC dependency from application layer
+	 * 
+	 * Current gRPC-dependent:
+	 * remote *client.Remote → eventstreamapi.EventStream_SubscribeClient
+	 * 
+	 * Proposed transport-agnostic:
+	 * transport Transport → Stream interface
+	 * 
+	 * Key Interfaces:
+	 * 
+	 * type Transport interface {
+	 *     Connect(ctx context.Context) error
+	 *     CreateStream(ctx context.Context) (Stream, error)
+	 *     Close() error
+	 * }
+	 * 
+	 * type Stream interface {
+	 *     Send(*cloudevents.Event) error      // Direct CloudEvent
+	 *     Receive() (*cloudevents.Event, error)  // Direct CloudEvent
+	 *     Close() error
+	 * }
+	 * 
+	 * Benefits:
+	 * - Application layer works with CloudEvents directly
+	 * - gRPC Protobuf conversion hidden in transport layer
+	 * - Same interface for gRPC, gRPC-WS, HTTP, Kafka
+	 * - Minimal code changes (just interface swap)
+	 * 
+	 * Implementation Strategy:
+	 * 1. Keep existing gRPC logic in transport implementations
+	 * 2. Wrap current Remote/EventStream with new interfaces
+	 * 3. Move format.ToProto/FromProto to gRPC transport layer
+	 */
 	remote           *client.Remote
 	appManager       *application.ApplicationManager
 	projectManager   *appproject.AppProjectManager

agent/agent.go

@@ -169,6 +169,20 @@ func (a *Agent) handleStreamEvents() error {
 		return err
 	}
 
+	/**
+	 * STREAM INTERFACE ABSTRACTION
+	 * 
+	 * Current: EventWriter accepts gRPC stream directly
+	 * a.eventWriter = event.NewEventWriter(stream)
+	 * 
+	 * Proposed: EventWriter accepts Stream interface
+	 * a.eventWriter = event.NewEventWriter(stream)  // Same call, different type
+	 * 
+	 * Key Change in EventWriter:
+	 * - streamWriter interface changes from gRPC-specific to CloudEvent-based
+	 * - Send(*eventstreamapi.Event) → Send(*cloudevents.Event)
+	 * - Transport layer handles Protobuf conversion internally
+	 */
 	a.eventWriter = event.NewEventWriter(stream)
 	go a.eventWriter.SendWaitingEvents(a.context)
 

agent/connection.go

@@ -39,7 +39,7 @@ The connection between an [agent](./components-terminology.md#agent) and the [pr
 
 *argocd-agent* is not designed to nor does it intend to replace any existing functionality in Argo CD. Its scope is to change the way how Applications are being deployed in a multi-cluster scenario, especially when there are more than a couple of clusters involved. And the project intends to require as minimal changes to Argo CD as possible, using any out-of-the-box Argo CD installation as the ultimate target.
 
-Under the hood, *argocd-agent* uses a message based protocol to establish a *bi-directional* exchange of messages. Bi-directional in this context means that both, the [principal](./components-terminology.md#principal) and the [agents](./components-terminology.md#agent) can send and receive messages simultaneously using the same connection, which is established exclusively by the agents. As of today, the underlying transport is gRPC based, but there are [plans](https://github.com/argoproj-labs/argocd-agent/issues/260) to make this extensible. The vision for this is that one could use a message bus implementation such as Kafka for the transport of messages if they wanted to.
+Under the hood, *argocd-agent* uses a message based protocol to establish a *bi-directional* exchange of messages. Bi-directional in this context means that both, the [principal](./components-terminology.md#principal) and the [agents](./components-terminology.md#agent) can send and receive messages simultaneously using the same connection, which is established exclusively by the agents. /* As of today, the underlying transport is gRPC based, but there are [plans](https://github.com/argoproj-labs/argocd-agent/issues/260) to make this extensible. The vision for this is that one could use a message bus implementation such as Kafka for the transport of messages if they wanted to. */
 
 ## Design principles
 
@@ -59,7 +59,7 @@ There are architectural variants in which a workload cluster will be dependent u
 
 **The initiating component is always the agent, not the control plane**
 
-Connections are established in one direction only: from the agent to the control plane. Neither the control plane nor the agents need to know exact details about the topology of the system, as long as the agents know which control plane to connect to. In some parts of this documentation, we mention something called a _bi-directional stream_. This refers to a gRPC mechanisms where both parties may randomly transmit and receive data from its peer, all while the connection is established only in one direction.
+Connections are established in one direction only: from the agent to the control plane. Neither the control plane nor the agents need to know exact details about the topology of the system, as long as the agents know which control plane to connect to. /* In some parts of this documentation, we mention something called a _bi-directional stream_. This refers to a gRPC mechanisms where both parties may randomly transmit and receive data from its peer, all while the connection is established only in one direction. */
 
 **Be lightweight by default but keep extensibility in mind**
 

docs/concepts/architecture.md

@@ -20,10 +20,10 @@ The protocol uses a **hub-and-spoke** architecture where:
 - **Principal**: Runs on the control plane, acts as the central coordination point
 - **Agents**: Run on workload clusters, initiate all connections to the principal
 - **Connections**: Always initiated by agents (never principal-to-agent)
-- **Streams**: Bidirectional gRPC streams over HTTP/2 (with HTTP/1.1 websocket fallback)
+- **Streams**: Bidirectional event streams using pluggable transports
 
 ```
-┌─────────────────┐    gRPC/HTTP2     ┌─────────────────┐
+┌─────────────────┐     Stream        ┌─────────────────┐
 │   Agent 1       │──────────────────►│   Principal     │
 │  (Workload)     │                   │ (Control Plane) │
 └─────────────────┘                   └─────────────────┘
@@ -34,6 +34,18 @@ The protocol uses a **hub-and-spoke** architecture where:
 └─────────────────┘
 ```
 
+### Transport Options
+
+**Direct Connection**:
+- gRPC streams over HTTP/2 (default)
+- WebSocket over HTTP/1.1
+- Server-Sent Events (SSE)
+
+**Message Queue**:
+- Kafka topics
+- Redis streams  
+- NATS messaging
+
 ### Protocol Stack
 
 ```
@@ -42,33 +54,28 @@ The protocol uses a **hub-and-spoke** architecture where:
 ├─────────────────────────────────────┤
 │        CloudEvents Format           │  ← Event envelope with metadata
 ├─────────────────────────────────────┤
-│         gRPC Streaming              │  ← Bidirectional streams
+│         Stream Interface            │  ← Send/Receive abstraction
+├─────────────────────────────────────┤
+│         Connection interface        │  ← Connection management
+├─────────────────────────────────────┤
+│        Transport Factory            │  ← Transport selection (gRPC, ws, Kafka)
 ├─────────────────────────────────────┤
-│        HTTP/2 (or HTTP/1+WS)        │  ← Transport layer
+│  ┌─────────────┬─────────────────┐  │
+│  │   Direct    │  Message Router │  │  ← Connection patterns
+│  │ Connection  │  (Kafka, etc.)  │  │
+│  └─────────────┴─────────────────┘  │
 ├─────────────────────────────────────┤
 │           TLS + mTLS                │  ← Security layer
 └─────────────────────────────────────┘
 ```
 
 ## Communication Protocol
 
-### gRPC Service Definition
-
-The core communication is defined by the `EventStream` service:
-
-```protobuf
-service EventStream {
-    rpc Subscribe(stream Event) returns (stream Event);
-    rpc Push(stream Event) returns (PushSummary);
-    rpc Ping(PingRequest) returns (PongReply);
-}
-```
-
 ### Connection Lifecycle
 
-1. **Authentication**: Agent presents JWT token with client certificate (optional)
+1. **Authentication**: Agent presents JWT token with transport-specific credentials
 2. **Authorization**: Principal validates agent identity and creates queue pair
-3. **Stream Establishment**: Bidirectional gRPC stream created
+3. **Stream Establishment**: Bidirectional event stream created using selected transport
 4. **Resync**: Initial synchronization based on agent mode
 5. **Event Processing**: Continuous bidirectional event exchange
 6. **Graceful Shutdown**: Connection cleanup and queue removal

docs/concepts/sync-protocol.md

@@ -123,6 +123,13 @@ type Stream interface {
 ```
 
 ### 2. Transport Factory
+CLI 로 --transport를 정할 때 함께 생성 됩니다.
+**현재 흐름:**
+1. Agent 시작 → gRPC 직접 연결 → 스트림 생성 → 이벤트 송수신
+
+**변경 후 흐름:**
+1. Agent 시작 → Factory로 transport 선택 → 연결 → 스트림 생성 → 이벤트 송수신
+
 ```
 // pkg/api/eventstreamapi/factory.go
 func NewFactory() *Factory

docs/concepts/transport-abstraction.md

@@ -29,7 +29,7 @@ The recommended approach for production deployments is to use ConfigMap entries
 - **Command Line Flag**: `--listen-port`
 - **Environment Variable**: `ARGOCD_PRINCIPAL_LISTEN_PORT`
 - **ConfigMap Entry**: `principal.listen.port`
-- **Description**: Port the gRPC server will listen on
+- **Description**: Port the transport server will listen on
 - **Type**: Integer
 - **Default**: `8443`
 - **Range**: 1-65535
@@ -320,7 +320,7 @@ The recommended approach for production deployments is to use ConfigMap entries
 - **Command Line Flag**: `--enable-websocket`
 - **Environment Variable**: `ARGOCD_PRINCIPAL_ENABLE_WEBSOCKET`
 - **ConfigMap Entry**: *(Not available in ConfigMap)*
-- **Description**: Use gRPC over WebSocket to stream events to agents
+- **Description**: Transport protocol to use for agent communication
 - **Type**: Boolean
 - **Default**: `false`
 - **Example**: `"false"`

docs/configuration/principal/configuration.md

@@ -19,7 +19,7 @@ argocd-agent transforms traditional multi-cluster Argo CD deployments by inverti
 **[Autonomous Mode](../concepts/agent-modes/autonomous.md)**: Applications are defined locally on workload clusters and synchronized back for observability. Perfect for edge deployments, air-gapped environments, or scenarios requiring local autonomy.
 
 ### Communication Protocol
-
+# Fix)))
 **gRPC with CloudEvents**: Efficient bi-directional communication using industry-standard protocols. The connection model supports intermittent connectivity and automatic reconnection.
 
 **mTLS Security**: All communication is secured with mutual TLS authentication. Agents authenticate to the principal using client certificates, eliminating the need for the control plane to store cluster credentials.

docs/features/index.md

@@ -16,4 +16,14 @@ spec:
     ports:
     - port: 6379
       protocol: TCP
+  # DNS 쿼리 규칙 추가
+  - to:
+    - namespaceSelector:
+        matchLabels:
+          kubernetes.io/metadata.name: kube-system
+    ports:
+    - port: 53
+      protocol: UDP
+    - port: 53
+      protocol: TCP
 

install/kubernetes/agent/agent-networkpolicy-redis.yaml

@@ -1,3 +1,5 @@
+namespace: argocd
+
 resources:
 - https://github.com/argoproj/argo-cd/manifests/cluster-install?ref=stable
 
@@ -184,3 +186,15 @@ patches:
     kind: ClusterRoleBinding
     metadata:
       name: argocd-applicationset-controller
+- target:
+    group: networking.k8s.io
+    version: v1
+    kind: NetworkPolicy
+    name: argocd-redis-network-policy
+  patch: |-
+    - op: add
+      path: /spec/ingress/0/from/-
+      value:
+        podSelector:
+          matchLabels:
+            app.kubernetes.io/name: argocd-agent-agent