diff --git a/docs/developer-guide/develop-operator.md b/docs/developer-guide/develop-operator.md index 5c0887371..864e3e99e 100644 --- a/docs/developer-guide/develop-operator.md +++ b/docs/developer-guide/develop-operator.md @@ -1,20 +1,26 @@ # Developing the bpfman-operator This section is intended to give developer level details regarding the layout and design of the bpfman-operator. -At its core the operator was implemented using the [operator-sdk framework](https://sdk.operatorframework.io/) +At its core the operator was implemented using the [operator-sdk framework](https://sdk.operatorframework.io/), which make those docs another good resource if anything is missed here. ## High level design overview -This repository houses two main processes, the `bpfman-agent` and the `bpfman-operator` along with CRD api definitions +This repository houses two main processes, the `bpfman-agent` and the `bpfman-operator`, along with CRD api definitions for `BpfProgram` and `*Program` Objects. The following diagram depicts how all these components work together to create a functioning operator. ![bpfman on K8s](../img/bpfman-on-k8s.png) +The `bpfman-operator` is running as a Deployment with a ReplicaSet of one. +It runs on the control plane and is composed of the containers `bpfman-operator` and +`kube-rbac-proxy`. +The operator is responsible for launching the bpfman Daemonset, which runs on every node. +The bpfman Daemonset is composed of the containers `bpfman`, `bpfman-agent`, and `node-driver-registrar`. + ## Building and Deploying -For building and deploying the bpfman-operator simply see the attached `make help` +For building and deploying the bpfman-operator, simply see the attached `make help` output. ```bash @@ -62,7 +68,6 @@ Build load-images-kind Load bpfman-agent, and bpfman-operator images into the running local kind devel cluster. bundle-build Build the bundle image. bundle-push Push the bundle image. - catalog-update Generate catalog yaml file. catalog-build Build a catalog image. catalog-push Push a catalog image. @@ -94,15 +99,15 @@ The following is a brief description of the main directories under `bpfman-opera **NOTE: Bolded directories contain auto-generated code** -- `apis/v1alpha1/*_types.go`: Contains the K8s CRD api definitions (`*_types.go`) for each version. +- `apis/v1alpha1/*_types.go`: Contains the K8s CRD api definitions (`*_types.go`) for each program type. - **apis/v1alpha1/zz_generated.*.go**: Contains the auto-generated register (`zz_generate.register.go`) - and deepcopy (`zz_generated.deepcopy.go`) methods. -- `bundle/`: Contains the OLM bundle manifests and metadata for the operator. + and deep copy (`zz_generated.deepcopy.go`) methods. +- **bundle/**: Contains the bundle manifests and metadata for the operator. More details can be found in the operator-sdk documentation. - `cmd/`: Contains the main entry-points for the bpfman-operator and bpfman-agent processes. - `config/`: Contains the configuration files for launching the bpfman-operator on a cluster. - - `bpfman-deployment/`: Contains static deployment yamls for the bpfman-daemon, this includes two containers, - one for `bpfman` and the other for the `bpfman-agent`. + - `bpfman-deployment/`: Contains static deployment yamls for the bpfman-daemon. + This includes two containers, one for `bpfman` and the other for the `bpfman-agent`. This DaemonSet yaml is NOT deployed statically by kustomize, instead it's statically copied into the operator image which is then responsible for deploying and configuring the bpfman-daemon DaemonSet. Lastly, this directory also contains the default config used to configure the bpfman-daemon, along with the @@ -110,8 +115,8 @@ The following is a brief description of the main directories under `bpfman-opera - `bpfman-operator-deployment/`: Contains the static deployment yaml for the bpfman-operator. This is deployed statically by kustomize. - `crd/`: Contains the CRD manifests for all of the bpfman-operator APIs. - - **bases/**: Is where the actual CRD definitions are stored. - These definitions are auto-generated by [controller-gen](https://book.kubebuilder.io/reference/controller-gen.html). + - **bases/**: This is where the actual CRD definitions are stored. + These definitions are auto-generated by [controller-gen](https://book.kubebuilder.io/reference/controller-gen.html). - `patches/`: Contains kustomize patch files for each Program Type, which enables a conversion webhook for the CRD and adds a directive for certmanager to inject CA into the CRD. - `default/`: Contains the default deployment configuration for the bpfman-operator. @@ -119,12 +124,12 @@ The following is a brief description of the main directories under `bpfman-opera - `openshift/`: Contains the Openshift specific deployment configuration for the bpfman-operator. - `prometheus/`: Contains the prometheus manifests used to deploy Prometheus to a cluster. At the time of writing this the bpfman-operator is NOT exposing any metrics to prometheus, but this is a future goal. - - **rbac/**: Contains rbac yamls for getting bpfman and the bpfman-operator up and running on Kubernetes. - - **bpfman-agent/**: Contains the rbac yamls for the bpfman-agent. + - **rbac/**: Contains RBAC yamls for getting bpfman and the bpfman-operator up and running on Kubernetes. + - **bpfman-agent/**: Contains the RBAC yamls for the bpfman-agent. They are automatically generated by kubebuilder via build tags in the bpfman-agent controller code. - - **bpfman-operator/**: Contains the rbac yamls for the bpfman-operator. + - **bpfman-operator/**: Contains the RBAC yamls for the bpfman-operator. They are automatically generated by kubebuilder via build tags in the bpfman-operator controller code. - - `samples/`: Contains sample CR definitions that can be deployed by users for each of our supported APIs. + - `samples/`: Contains CRD samples that can be deployed by users for each of our supported APIs. - `scorecard/`: Contains the scorecard manifests used to deploy scorecard to a cluster. At the time of writing this the bpfman-operator is NOT running any scorecard tests. - `test/`: Contains the test manifests used to deploy the bpfman-operator to a kind cluster for integration testing. @@ -185,24 +190,91 @@ follow best practices describe in See [container-storage-interface/spec/spec.md](https://github.com/container-storage-interface/spec/blob/master/spec.md) for more details. -### Generated Files +### Generated Files and Adding New Program Type The [operator-sdk framework](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/#project-layout) -will generate multiple categories of files (Custom Resource Definitions (CRD), RBAC ClusterRole, Webhook Configuration, +will generate multiple categories of files (Custom Resource Definitions (CRD), RBAC Role and ClusterRole, Webhook Configuration, typed client, listeners and informers code, etc). -If any of the -[bpfman-operator/apis/v1alpha1/*Program_types.go](https://github.com/bpfman/bpfman/tree/main/bpfman-operator/apis/v1alpha1) -files are modified, then regenerate these files using: +When adding a new Program Type or if any of these files are modified, then the auto-generated files must be regenerated: + +* [bpfman-operator/apis/v1alpha1/*_types.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1): + Contains the K8s CRD api definitions (`*_types.go`) for each program type. + When adding a new Program Type, add a file here for the new type. +* [bpfman-operator/config/crd/kustomization.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/crd/kustomization.yaml): + This file specifies the output location for the generated yaml files that define the Custom Resource + Definitions (CRDs). + This file must be updated when a new CRD needs to be generated. +* [bpfman-operator/config/crd/patches/](https://github.com/bpfman/bpfman-operator/tree/main/config/crd/patches): + There is a `cainjection_in_*programs.yaml` and `webhook_in_*programs.yaml` file for each Program Type + in this directory. + When adding a new Program Type, add files here for the new type. +* [bpfman-operator/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml): + This file has a list of bpfman Custom Resource Definitions. + When adding a new Program Type, an entry for the new type must be added to this file. +* [bpfman-operator/config/samples/bpfman.io_v1alpha1_\*_\*program.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/manifests/bases/bpfman-operator.clusterserviceversion.yaml): + Contains a sample of how to deploy each Program Type. + When adding a new Program Type, add a file here for the new type. +* [bpfman-operator/controllers/bpfman-agent/*_program.go](https://github.com/bpfman/bpfman-operator/tree/main/controllers/bpfman-agent): + Contains the Program Type specific reconciler for the bpfman-agent. + If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated. + When adding a new Program Type, add a file here for the new type. +* [bpfman-operator/controllers/bpfman-agent/common.go](https://github.com/bpfman/bpfman-operator/blob/main/controllers/bpfman-agent/common.go): + Contains the common reconciler code for the bpfman-agent. + If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated. + When adding a new Program Type, `//+kubebuilder:rbac` directives need to be added for the new type. +* [bpfman-operator/controllers/bpfman-operator/*_program.go](https://github.com/bpfman/bpfman-operator/tree/main/controllers/bpfman-operator): + Contains the Program Type specific reconciler for the bpfman-operator. + If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated. + When adding a new Program Type, add a file here for the new type. +* [bpfman-operator/controllers/bpfman-operator/common.go](https://github.com/bpfman/bpfman-operator/blob/main/controllers/bpfman-operator/common.go): + Contains the common reconciler code for the bpfman-operator. + If the `//+kubebuilder:rbac` directives are added or changed, the associated `role.yaml` must be regenerated. + When adding a new Program Type, `//+kubebuilder:rbac` directives need to be added for the new type. + +Then regenerate the generated files using: ```bash cd bpfman-operator/ make generate ``` -This command will generate all auto-generated code. There are commands to generate each sub-category if needed. See `make help` to list all the generate commands. +This command will generate the following files: + +* [bpfman-operator/apis/v1alpha1/zz_generate.register.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1): + Contains the auto-generated register methods for all the Program Types. +* [bpfman-operator/apis/v1alpha1/zz_generated.deepcopy.go](https://github.com/bpfman/bpfman-operator/tree/main/apis/v1alpha1): + Contains the deep copy methods for all the Program Types. +* [bpfman-operator/config/crd/bases/bpfman.io_*programs.yaml](https://github.com/bpfman/bpfman-operator/tree/main/config/crd/bases): + Contains the yaml files that the define the Custom Resource Definitions (CRDs). +* [bpfman-operator/config/rbac/bpfman-agent/role.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/rbac/bpfman-agent/role.yaml): + Contains the `Role` and `ClusterRole` definitions for bpfman-agent. + Controls the bpfman-agent access rights to each of the Program Type CRDs. + Generated from the `//+kubebuilder:rbac` directives in source code. +* [bpfman-operator/config/rbac/bpfman-operator/role.yaml](https://github.com/bpfman/bpfman-operator/blob/main/config/rbac/bpfman-operator/role.yaml): + Contains the `Role` and `ClusterRole` definitions for bpfman-operator. + Controls the bpfman-operator access rights to each of the Program Type CRDs. + Generated from the `//+kubebuilder:rbac` directives in source code. +* [bpfman-operator/pkg/client/*](https://github.com/bpfman/bpfman-operator/tree/main/pkg/client): + Everything under this directory is generated. + Contains client Golang code to enable applications to easily integrate with bpfman. + +Then regenerate the generated bundle files using (Note: `make bundle` calls `make generate`): + +```bash +cd bpfman-operator/ +make bundle +``` + +This command will generate the following files: + +* [bpfman-operator/bundle/*](https://github.com/bpfman/bpfman-operator/tree/main/bundle): + Contains the bundle manifests and metadata for the operator. + This bundle is used to deploy the CRDs in a cluster. + More details can be found in the operator-sdk documentation. + ### Building To run in Kubernetes, bpfman components need to be containerized. @@ -224,7 +296,7 @@ make build-images If the `make build` command is skipped above, the code will be built in the build-images command. If the `make build` command is run, the built code will be leveraged in this step. -This command generates the following images: +This command generates the following local images: ```bash docker images @@ -235,6 +307,31 @@ quay.io/bpfman/bpfman-operator latest 4fe444b7abf1 2 minutes ago 141MB : ``` +When running in KIND (see below), the local images will be loaded into the KIND +environment. +There may be times when the image need to be built and pushed to a remote repository +like quay.io so they can be shared or loaded in a remote cluster. +The `Makefile` uses the following variables to manage the location of the built images: + +* **BPFMAN_IMG:** The bpfman image is not built from the bpfman operator repository, but the + bpfman operator yaml files control which image is loaded in the cluster. + Use this variable to manage the bpfman image loaded by the bpfman-operator. + If not specified, defaults to `quay.io/bpfman/bpfman:latest`. +* **BPFMAN_AGENT_IMG:** The bpfman agent image. + If not specified, defaults to `quay.io/bpfman/bpfman-agent:latest`. +* **BPFMAN_OPERATOR_IMG:** The bpfman operator image. + If not specified, defaults to `quay.io/bpfman/bpfman-operatorman:latest`. + +To build the bpfman operator images with custom image locations, use something similar to: + +```bash +cd bpfman-operator/ +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \ +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \ +BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \ +make build-images +``` + ## Running Locally in KIND [Deploying the bpfman-operator](../getting-started/operator-quick-start.md) goes into more detail on ways to @@ -246,6 +343,13 @@ cd bpfman-operator/ make run-on-kind ``` +> **NOTE:** By default, bpfman-operator deploys bpfman with CSI enabled. +CSI requires Kubernetes v1.26 due to a PR +([kubernetes/kubernetes#112597](https://github.com/kubernetes/kubernetes/pull/112597)) +that addresses a gRPC Protocol Error that was seen in the CSI client code and it doesn't appear to have +been backported. +It is recommended to install kind v0.20.0 or later. + The `make run-on-kind` will run the `make build-images` if the images do not exist or need updating. Then rebuild and load a fresh build run: @@ -269,6 +373,239 @@ BPFMAN_IMG= BPFMAN_AGENT_IMG= BPFMAN_OPERATOR_IM See [Kubernetes Operator Tests](https://bpfman.io/main/developer-guide/testing/#kubernetes-operator-tests). +## Deploy To Existing Cluster + +There are several ways to deploy bpfman to an existing Kubernetes cluster. +The cluster needs to be up and running and specified in ~/.kube/config file. + +* **OperatorHub:** bpfman can be installed in a cluster from either the community OperatorHub + ([OperatorHub.io](https://operatorhub.io/)) or to an OpenShift Cluster via the OpenShift + Console and the builtin Console OperatorHub. + This is the recommended method for installing the latest release of bpfman/bpfman-operator. + +* **Custom OpenShift Console OperatorHub Bundle:** Custom bpfman/bpfman-operator image can be + installed in via OpenShift Console OperatorHub. + This is the recommended method when developing in bpfman/bpfman-operator, building custom images, + and needing to test from OpenShift Console OperatorHub. + +* **Manually with Kustomize:** bpfman can be manually installed to an OpenShift cluster with + Kustomize and raw manifests. + This is the recommended method when developing in bpfman/bpfman-operator, building custom images, + and wanting to test in an OpenShift cluster. + +* **Manually with OLM Bundle:** The other option for installing the bpfman-operator is to install + it using [OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles). + +### OperatorHub + +When installing the latest release of bpfman/bpfman-operator, bpfman can be installed in a +cluster from either the community OperatorHub ([OperatorHub.io](https://operatorhub.io/)) +or to an OpenShift Cluster via the OpenShift Console and the builtin Console OperatorHub. + +#### OperatorHub.io + +To install from the community OperatorHub, go to ([OperatorHub.io](https://operatorhub.io/)) and +search for bpfman: + +![Community OperatorHub.io](../img/operatorhub/OperatorHub_Community_bpfman.png) + +Click on the bpfman Operator, which will take you to the installation screen: + +![Install](../img/operatorhub/OperatorHub_Community_bpfman_install.png) + +Click on the `Install` button, which will take you to the installation instructions, which are a set +of commands to run to install the bpfman Operator: + +![Commands](../img/operatorhub/OperatorHub_Community_bpfman_commands.png) + +#### OperatorHub via OpenShift Console + +To install from the OpenShift Console, from within the OpenShift Console, find `OperatorHub`, which +is under `Operators` on the left hand side of the page. +Then search for bpfman: + +![OCP Console Search](../img/operatorhub/OperatorHub_RedHat_bpfman.png) + +There should be two options, `Community` and `Red Hat`. +The `Community` based Operator tracks the releases from this repository. +The `Red Hat` based Operator is the downstream version from this repository and releases +with each OpenShift release. +Click on the operator to be installed: + +![OCP Console Install](../img/operatorhub/OperatorHub_RedHat_bpfman_install.png) + +This provides the details on the operator. +Select the desired Version and click the `Install` button. + +![OCP Console Details](../img/operatorhub/OperatorHub_RedHat_bpfman_details.png) + +This provides similar details on the operator in a popup window. +Select the desired Version and click the `Install` button. +This will install the bpfman Operator on the cluster. + +### Custom OpenShift Console OperatorHub Bundle + +If developing in bpfman/bpfman-operator and a custom image needs to be loaded +from OpenShift Console OperatorHub, then make the changes to bpfman/bpfman-operator. +Once the changes compile and are ready to be tested, build and push the container +images: + +```bash +cd bpfman-operator/ + +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \ +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \ +BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \ +make build-images + +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \ +BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \ +make push-images +``` + +Next, a bundle and catalog needs to be built and pushed: + +```bash +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman:test \ +BPFMAN_AGENT_IMG=quay.io/$QUAY_USER/bpfman-agent:test \ +BPFMAN_OPERATOR_IMG=quay.io/$QUAY_USER/bpfman-operator:test \ +BUNDLE_IMG=quay.io/$QUAY_USER/bpfman-operator-bundle:developement \ +make bundle bundle-build bundle-push + +CATALOG_IMG=quay.io/$QUAY_USER/bpfman-operator-catalog:developement \ +make catalog-build catalog-push +``` + +Once the bundle and catalog are built, make sure the cluster is up and +running and specified in ~/.kube/config file. +Then deploy the catalog: + +```bash +make catalog-deploy +``` + +Now the new catalog should show up in the OperatorHub (may have to refresh or restart the search +if OperatorHub was already up). +An additional option should be presented, `Bpfman Operator development`. +This can be now be installed as described above. + +![OCP Console Devel](../img/operatorhub/OperatorHub_RedHat_bpfman_devel.png) + +To clean up at a later time, execute: + +```bash +make catalog-undeploy +``` + +### Manually with Kustomize + +To manually install with Kustomize and raw manifests, execute the following commands. The Openshift cluster needs to be up and running and specified in ~/.kube/config file. + +```bash +cd bpfman-operator/ +make deploy-openshift +``` + +To clean up at a later time, run: + +```bash +make undeploy-openshift +``` + +### Manually with OLM Bundle + +The other option for installing the bpfman-operator is to install it using +[OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles). + +First setup the namespace and certificates for the operator with: + +```bash +cd bpfman-operator +kubectl apply -f ./hack/ocp-scc-hacks.yaml +``` + +Then use `operator-sdk` to install the bundle like so: + +```bash +./bin/operator-sdk run bundle quay.io/bpfman/bpfman-operator-bundle:latest --namespace openshift-bpfman +``` + +To clean up at a later time, run: + +```bash +./bin/operator-sdk cleanup bpfman-operator +kubectl delete -f ./hack/ocp-scc-hacks.yaml +``` + +## Verify the Installation + +Regardless of the deployment method, if the `bpfman-operator` was deployed successfully, +you will see the `bpfman-daemon` and `bpfman-operator` pods running without errors: + +```bash +kubectl get pods -n bpfman +NAME READY STATUS RESTARTS AGE +bpfman-daemon-w24pr 3/3 Running 0 130m +bpfman-operator-78cf9c44c6-rv7f2 2/2 Running 0 132m +``` + +For further verification, load a sample eBPF Program onto the cluster using +[Deploy an eBPF Program to the cluster](../getting-started/operator-quick-start.md#deploy-an-ebpf-program-to-the-cluster). + +## bpfman-agent Profiling + +bpfman-agent process use port `6060` for Golang profiling to be able to get the different profiles. + +1. Set port-forward rule in a different terminal: + + ```bash + kubectl get pods -n bpfman + NAME READY STATUS RESTARTS AGE + bpfman-daemon-76v57 3/3 Running 0 14m + bpfman-operator-7f67bc7c57-ww52z 2/2 Running 0 14m + + kubectl -n bpfman port-forward bpfman-daemon-76v57 6060 + ``` + +2. Download the required profiles: + + `curl -o http://localhost:6060/debug/pprof/` + + Where can be: + + | profile | description | + |--------------|-------------------------------------------------------------------------------| + | allocs | A sampling of all memory allocations | + | block | Stack traces that led to blocking on synchronization primitives | + | cmdline | The command line invocation of the current program | + | goroutine | Stack traces of all current goroutines | + | heap | A sampling of memory allocations of live objects. | + | | You can specify the gc GET parameter to run GC before taking the heap sample. | + | mutex | Stack traces of holders of contended mutexes | + | profile | CPU profile. | + | | You can specify the duration in the seconds GET parameter. | + | threadcreate | Stack traces that led to the creation of new OS threads | + | trace | A trace of execution of the current program. | + | | You can specify the duration in the seconds GET parameter. | + + Example: + + ```bash + curl "http://localhost:6060/debug/pprof/trace?seconds=20" -o trace + curl "http://localhost:6060/debug/pprof/profile?duration=20" -o cpu + curl "http://localhost:6060/debug/pprof/heap?gc" -o heap + curl "http://localhost:6060/debug/pprof/allocs" -o allocs + curl "http://localhost:6060/debug/pprof/goroutine" -o goroutine + ``` + +3. Use [go tool pprof](https://go.dev/blog/pprof) to dig into the profiles (go tool trace + for the trace profile) or use web interface. + For example: + + ```bash + go tool pprof -http=:8080 cpu + ``` + ## Troubleshooting ### Metrics/Health port issues diff --git a/docs/getting-started/operator-quick-start.md b/docs/getting-started/operator-quick-start.md index 1f37acfb7..ae41a2330 100644 --- a/docs/getting-started/operator-quick-start.md +++ b/docs/getting-started/operator-quick-start.md @@ -26,7 +26,7 @@ After reviewing the possible make targets it's quick and easy to get bpfman depl via a [KIND cluster](https://kind.sigs.k8s.io/) with: ```bash -cd bpfman/bpfman-operator +cd bpfman-operator make run-on-kind ``` @@ -40,67 +40,12 @@ make run-on-kind ### Deploy To Openshift Cluster -First deploy the operator with one of the following two options: - -#### 1. Manually with Kustomize - -To install manually with Kustomize and raw manifests simply run the following -commands. -The Openshift cluster needs to be up and running and specified in `~/.kube/config` -file. - -```bash -cd bpfman/bpfman-operator -make deploy-openshift -``` - -Which can then be cleaned up at a later time with: - -```bash -make undeploy-openshift -``` - -#### 2. Via the OLM bundle - -The other option for installing the bpfman-operator is to install it using -[OLM bundle](https://www.redhat.com/en/blog/deploying-operators-olm-bundles). - -First setup the namespace and certificates for the operator with: - -```bash -cd bpfman/bpfman-operator -oc apply -f ./hack/ocp-scc-hacks.yaml -``` - -Then use `operator-sdk` to install the bundle like so: - -```bash -operator-sdk run bundle quay.io/bpfman/bpfman-operator-bundle:latest --namespace openshift-bpfman -``` - -Which can then be cleaned up at a later time with: - -```bash -operator-sdk cleanup bpfman-operator -``` - -followed by - -```bash -oc delete -f ./hack/ocp-scc-hacks.yaml -``` - -## Verify the Installation - -Independent of the method used to deploy, if the bpfman-operator came up successfully -you will see the bpfman-daemon and bpfman-operator pods running without errors: - -```bash -$ kubectl get pods -n bpfman -NAME READY STATUS RESTARTS AGE -bpfman-daemon-w24pr 3/3 Running 0 130m -bpfman-operator-78cf9c44c6-rv7f2 2/2 Running 0 132m -``` +The recommend way of deploying bpfman to an OpenShift cluster is via the +OpenShift Console and using Operator Hub. +This is described in +[OperatorHub via OpenShift Console](../developer-guide/develop-operator.md#operatorhub-via-openshift-console). +For other options, see +[Deploy To Existing Cluster](../developer-guide/develop-operator.md#deploy-to-existing-cluster). ## API Types Overview @@ -162,7 +107,7 @@ Any of the cluster scoped samples can be applied as is. To test the deployment simply deploy one of the sample `xdpPrograms`: ```bash -cd bpfman/bpfman-operator/ +cd bpfman-operator/ kubectl apply -f config/samples/bpfman.io_v1alpha1_xdp_pass_xdpprogram.yaml ``` diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman.png b/docs/img/operatorhub/OperatorHub_Community_bpfman.png new file mode 100644 index 000000000..12d947388 Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman.png differ diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png b/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png new file mode 100644 index 000000000..27fc6ac32 Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman_commands.png differ diff --git a/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png b/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png new file mode 100644 index 000000000..dbc71f545 Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_Community_bpfman_install.png differ diff --git a/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png b/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png new file mode 100644 index 000000000..c1af346ca Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_SecurityProfileOperator.png differ diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png new file mode 100644 index 000000000..ed812b61d Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman.png differ diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png new file mode 100644 index 000000000..fe0a26b0b Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_details.png differ diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png new file mode 100644 index 000000000..1032acd50 Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_devel.png differ diff --git a/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png new file mode 100644 index 000000000..cd868d004 Binary files /dev/null and b/docs/img/operatorhub/OperatorHub_RedHat_bpfman_install.png differ diff --git a/examples/config/base/go-xdp-counter/deployment.yaml b/examples/config/base/go-xdp-counter/deployment.yaml index 6cabe2d2b..c853e41c6 100644 --- a/examples/config/base/go-xdp-counter/deployment.yaml +++ b/examples/config/base/go-xdp-counter/deployment.yaml @@ -1,20 +1,15 @@ --- apiVersion: v1 -kind: Namespace -metadata: - name: go-xdp-counter ---- -apiVersion: v1 kind: ServiceAccount metadata: name: bpfman-app-go-xdp-counter - namespace: go-xdp-counter + namespace: bpfman --- apiVersion: apps/v1 kind: DaemonSet metadata: name: go-xdp-counter-ds - namespace: go-xdp-counter + namespace: bpfman labels: k8s-app: go-xdp-counter spec: