メニュー
ConfigCenter subsystem — ConfCenter trait abstraction, FileSystemCenter and KubernetesCenter implementations, unified Workqueue + ResourceProcessor pipeline.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Conventions shared by the in-repo binaries (edgion-controller, edgion-gateway, edgion-cli) — project overview, command line / directory / config-path conventions, Core layering conventions, resource system.
KubernetesCenter implementation — K8s Reflector watching, leader election, HA mode, ResourceController lifecycle, status writeback.
edgion-controller control plane architecture — overall design, startup/shutdown, Admin API, ConfigCenter, Workqueue, ResourceProcessor, Requeue, CacheServer, ACME service.
Route matching overview — multi-stage pipeline (Listener→Domain→Path→DeepMatch), per-listener isolation, registration flow, atomic swap.
TLS subsystem overview — TLS Store, SNI matching, certificate management, BoringSSL/OpenSSL backend selection.
edgion-gateway data plane architecture — Pingora integration, route matching, TLS management, plugin system, load balancing, backend discovery, observability, LinkSys.
| name | config-center |
| description | ConfigCenter subsystem — ConfCenter trait abstraction, FileSystemCenter and KubernetesCenter implementations, unified Workqueue + ResourceProcessor pipeline. |
The ConfigCenter is a core Controller subsystem responsible for receiving resource configuration from various sources. Both backends share the same Workqueue + ResourceProcessor pipeline; only the event source and persistence layer differ.
The ConfigCenter defines a unified interface via the ConfCenter trait, which contains two groups of capabilities:
get_one, set_one, create_one, update_one, liststart, ready check, reload, shutdownWhether the underlying backend is the file system or the Kubernetes API, the upper-layer Workqueue and ResourceProcessor pipeline is identical. Resource changes from the event source enter the Workqueue uniformly for dedup and delayed (coalesced) requeue, then the ResourceProcessor performs validation, preparse, processing, and dispatch.
| File | Topic | Recommended reading scenario |
|---|---|---|
| 00-overview.md | ConfCenter trait architecture | Understanding the ConfigCenter abstraction design |
| 01-file-system.md | FileSystemCenter implementation | Local development / debugging mode |
| 02-kubernetes/ | Kubernetes ConfigCenter | Production environments, HA, leader election |
| (etcd has no standalone document) | EtcdCenter implementation | Non-K8s production, single-Controller deployment |
ConfCenter trait
├── CenterApi (CRUD: get_one, set_one, create_one, update_one, list)
└── CenterLifeCycle (start, ready check, reload, shutdown)
FileSystemCenter KubernetesCenter EtcdCenter
├── Local YAML files ├── K8s API Server ├── etcd KV store
├── inotify watching ├── Reflector watch ├── etcd watch events
├── .status files ├── Status subresource ├── No status persistence
├── No leader elect ├── Lease-based election ├── No leader election
└── Use: dev/test └── Use: production K8s └── Use: non-K8s production
EtcdCenter design constraint: EtcdStorage::create_one/update_one are non-atomic check-then-write operations. The design assumes a single Controller exclusively owns etcd; concurrent writes from multiple Controllers to the same etcd instance are not supported.