|
12 | 12 | [](https://bestpractices.coreinfrastructure.org/projects/6615) |
13 | 13 | [](https://app.fossa.com/projects/git%2Bgithub.com%2Fopen-feature%2Fopen-feature-operator?ref=badge_shield) |
14 | 14 |
|
15 | | -The OpenFeature Operator is a Kubernetes native operator that allows you to expose feature flags to your applications. It injects a [flagD](https://github.com/open-feature/flagd) sidecar into your pod and allows you to poll the flagD server for feature flags in a variety of ways. |
16 | 15 |
|
17 | | -## Deploy the latest release |
| 16 | +## Get started |
18 | 17 |
|
19 | | -_Requires [cert manager](https://cert-manager.io/docs/installation/kubernetes/) installed (see why [here](#cert-manager))_ |
| 18 | +The OpenFeature Operator is a Kubernetes native operator that allows you to expose feature flags to your applications. It injects a [flagD](https://github.com/open-feature/flagd) sidecar into your pod and allows you to poll the flagD server for feature flags in a variety of ways. To get started, follow the installation instructions in the [docs](./docs/installation.md). |
20 | 19 |
|
21 | | -## Helm |
| 20 | +## Contributing |
22 | 21 |
|
23 | | -Install cert manager (if not already installed): |
24 | | -``` |
25 | | -kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.yaml |
26 | | -``` |
27 | | -Install helm charts: |
28 | | -``` |
29 | | -helm repo add openfeature https://open-feature.github.io/open-feature-operator/ |
30 | | -``` |
| 22 | +See [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute to the OpenFeature project. |
31 | 23 |
|
32 | | -``` |
33 | | -helm install ofo openfeature/ofo |
34 | | -``` |
| 24 | +Our community meetings are held regularly and open to everyone. Check the [OpenFeature community calendar](https://calendar.google.com/calendar/u/0?cid=MHVhN2kxaGl2NWRoMThiMjd0b2FoNjM2NDRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) for specific dates and for the Zoom meeting links. |
35 | 25 |
|
| 26 | +Thanks so much to our contributors. |
36 | 27 |
|
37 | | -## Kubectl |
| 28 | +<a href="https://github.com/open-feature/flagd/graphs/contributors"> |
| 29 | + <img src="https://contrib.rocks/image?repo=open-feature/open-feature-operator" /> |
| 30 | +</a> |
38 | 31 |
|
39 | | -<!---x-release-please-start-version--> |
40 | | - |
41 | | -``` |
42 | | -kubectl create namespace open-feature-operator-system |
43 | | -kubectl apply -f https://github.com/open-feature/open-feature-operator/releases/download/v0.2.20/release.yaml |
44 | | -``` |
45 | | - |
46 | | -<!---x-release-please-end--> |
47 | | - |
48 | | - |
49 | | -### Release contents |
50 | | - |
51 | | -- `release.yaml` contains the configuration of: |
52 | | - - `FeatureFlagConfiguration` `CustomResourceDefinition` (custom type that holds the configured state of feature flags). |
53 | | - - Standard kubernetes primitives (e.g. namespace, accounts, roles, bindings, configmaps). |
54 | | - - Operator controller manager service. |
55 | | - - Operator webhook service. |
56 | | - - Deployment with containers kube-rbac-proxy & manager. |
57 | | - - `MutatingWebhookConfiguration` (configures webhooks to call the webhook service). |
58 | | - |
59 | | -### How to deploy a flag consuming application |
60 | | - |
61 | | -_Prerequisite: the release and certificates have been deployed as outlined above._ |
62 | | - |
63 | | -Deploying a flag consuming application requires (at minimum) the creation of the following 2 resources (an example can be found [here](./config/samples/end-to-end.yaml)): |
64 | | - |
65 | | -#### FeatureFlagConfiguration |
66 | | - |
67 | | -This is a `CustomResourceDefinition` which contains the feature flags specification and a name of the spec. |
68 | | - |
69 | | -#### Deployment (or Statefulset/Daemonset) |
70 | | - |
71 | | -This is a kubernetes primitive for deploying an application. The metadata annotations must include `openfeature.dev/featureflagconfiguration` |
72 | | -with the value set as the name of the `FeatureFlagConfiguration` created in the step prior. |
73 | | - |
74 | | -e.g. |
75 | | -``` |
76 | | -metadata: |
77 | | - annotations: |
78 | | - openfeature.dev/featureflagconfiguration: "demo" |
79 | | -``` |
80 | | - |
81 | | -## Architecture |
82 | | - |
83 | | -As per the issue [here](https://github.com/open-feature/ofep/issues/1) |
84 | | - |
85 | | -As per v0.1.1, the default sync provider has been optimized as per this OpenFeature Enhancement Proposal [issue](https://github.com/open-feature/ofep/blob/main/004-OFEP-kubernetes-sync-service.md). |
86 | | - |
87 | | -High level architecture is as follows: |
88 | | - |
89 | | -<img src="images/arch-0.png" width="700"> |
90 | | - |
91 | | -### Requirements |
92 | | - |
93 | | -#### Namespace |
94 | | - |
95 | | -The Kubernetes resources created by OpenFeature Operator are under the `open-feature-operator-system` namespace. This means |
96 | | -any resources that want to communicate with the OFO system (e.g. an application calling flag evaluations) must fall under |
97 | | -this namespace. |
98 | | - |
99 | | -#### Cert Manager |
100 | | - |
101 | | -OpenFeature Operator is a server that communicates with Kubernetes components within the cluster, as such it requires a means of |
102 | | -authorizing requests between peers. [Cert manager](https://cert-manager.io/) handles the authorization by |
103 | | -adding certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of |
104 | | -obtaining, renewing and using those certificates. |
105 | | - |
106 | | -## Example |
107 | | - |
108 | | -When wishing to leverage feature flagging within the local pod, the following steps are required: |
109 | | - |
110 | | -1. Create a new feature flag custom resource. |
111 | | - |
112 | | -_See [here](config/samples/crds/custom_provider.yaml) for additional custom resource parameters_ |
113 | | - |
114 | | -``` |
115 | | -apiVersion: core.openfeature.dev/v1alpha2 |
116 | | -kind: FeatureFlagConfiguration |
117 | | -metadata: |
118 | | - name: featureflagconfiguration-sample |
119 | | -spec: |
120 | | - featureFlagSpec: |
121 | | - flags: |
122 | | - foo: |
123 | | - state: "ENABLED" |
124 | | - variants: |
125 | | - "bar": "BAR" |
126 | | - "baz": "BAZ" |
127 | | - defaultVariant: "bar", |
128 | | - targeting: {} |
129 | | -``` |
130 | | - |
131 | | -1. Reference the CR within the pod spec annotations |
132 | | -The `openfeature.dev/featureflagconfiguration` annotation is a comma separated list of CR references, listed as `{namespace}/{name}`. e.g. `"default/featureflagconfiguration-sample, test/featureflagconfiguration-sample-2"`. If no namespace is defined, it is assumed that the flag configuration is in the same namespace as the deployed pod. |
133 | | - |
134 | | -``` |
135 | | -apiVersion: v1 |
136 | | -kind: Pod |
137 | | -metadata: |
138 | | - name: nginx |
139 | | - annotations: |
140 | | - openfeature.dev/enabled: "true" |
141 | | - openfeature.dev/featureflagconfiguration: "default/featureflagconfiguration-sample" |
142 | | -spec: |
143 | | - containers: |
144 | | - - name: nginx |
145 | | - image: nginx:1.14.2 |
146 | | - ports: |
147 | | - - containerPort: 80 |
148 | | -``` |
149 | | - |
150 | | -3. Example usage from host container |
151 | | - |
152 | | -``` |
153 | | -root@nginx:/# curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"foo","context":{}}' -H "Content-Type: application/json" |
154 | | -{"value":"BAR","reason":"DEFAULT","variant":"bar"} |
155 | | -``` |
156 | | - |
157 | | -### Running the operator locally |
158 | | - |
159 | | -#### Create a local cluster with cert manager and our operator |
160 | | - |
161 | | -1. Create a local cluster with MicroK8s or Kind (forward requests from your localhost:30000 to your cluster, see MicroK8s/Kind doc) |
162 | | -1. `IMG=ghcr.io/open-feature/open-feature-operator:main make deploy-operator` |
163 | | - |
164 | | -#### Run the example |
165 | | - |
166 | | -1. Apply the end-to-end example: `kubectl apply -f config/samples/end-to-end.yaml` |
167 | | -1. Visit `http://localhost:30000/` |
168 | | -1. Update the value of the `defaultVariant` field in the custom resource instance in `config/samples/end-to-end.yaml` and re-apply to update the flag value! |
169 | | -1. Visit `http://localhost:30000/` and see the change! |
170 | | - |
171 | | -## Testing |
172 | | - |
173 | | -Run `make test` to run the test suite. The controller integration tests use [envtest](https://book.kubebuilder.io/reference/envtest.html), this sets up and starts an instance of etcd and the Kubernetes API server, without kubelet, controller-manager or other components. |
174 | | -This provides means of asserting that the Kubernetes components reach the desired state without the overhead of using an actual cluster, keeping |
175 | | -test runtime and resource consumption down. |
176 | | - |
177 | | -## Releases |
178 | | - |
179 | | -This repo uses _Release Please_ to release packages. Release Please sets up a running PR that tracks all changes for the library components, and maintains the versions according to [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), generated when [PRs are merged](https://github.com/amannn/action-semantic-pull-request). When Release Please's running PR is merged, any changed artifacts are published. |
| 32 | +Made with [contrib.rocks](https://contrib.rocks). |
0 commit comments