mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
[enterprise-4.19] OSDOCS#14398: Remove docs for the Operator SDK
This commit is contained in:
Michael Ryan Peter
@@ -24,9 +24,6 @@ ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* xref:../../networking/configuring-a-custom-pki.adoc#configuring-a-custom-pki[Configuring a custom PKI] (custom CA certificate)
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
* Developing Operators that support proxy settings for xref:../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-run-proxy_osdk-golang-tutorial[Go], xref:../../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-run-proxy_osdk-ansible-tutorial[Ansible], and xref:../../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-run-proxy_osdk-helm-tutorial[Helm]
|
||||
|
||||
|
||||
include::modules/olm-overriding-proxy-settings.adoc[leveloffset=+1]
|
||||
include::modules/olm-injecting-custom-ca.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -17,8 +17,6 @@ and Operator catalog maintainers can create and manage custom catalogs packaged
|
||||
[IMPORTANT]
|
||||
====
|
||||
Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. As a result, Operators are unable to use removed APIs starting with the version of {product-title} that uses the Kubernetes version that removed the API.
|
||||
|
||||
If your cluster is using custom catalogs, see xref:../../operators/operator_sdk/osdk-working-bundle-images#osdk-control-compat_osdk-working-bundle-images[Controlling Operator compatibility with {product-title} versions] for more details about how Operator authors can update their projects to help avoid workload issues and prevent incompatible upgrades.
|
||||
====
|
||||
|
||||
[role="_additional-resources"]
|
||||
@@ -138,4 +136,4 @@ include::modules/olm-removing-catalogs.adoc[leveloffset=+1]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
include::modules/sd-olm-removing-catalogs.adoc[leveloffset=+1]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
@@ -13,15 +13,6 @@ include::modules/operators-overview.adoc[leveloffset=+1]
|
||||
|
||||
As an Operator author, you can perform the following development tasks for OLM-based Operators:
|
||||
|
||||
** xref:../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Install Operator SDK CLI].
|
||||
// The Operator quickstarts aren't published for OSD/ROSA, so for OSD/ROSA, these xrefs point to the tutorials instead.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
** Create xref:../operators/operator_sdk/golang/osdk-golang-quickstart.adoc#osdk-golang-quickstart[Go-based Operators], xref:../operators/operator_sdk/ansible/osdk-ansible-quickstart.adoc#osdk-ansible-quickstart[Ansible-based Operators], and xref:../operators/operator_sdk/helm/osdk-helm-quickstart.adoc#osdk-helm-quickstart[Helm-based Operators].
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
** Create xref:../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-golang-tutorial[Go-based Operators], xref:../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-ansible-tutorial[Ansible-based Operators], and xref:../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-helm-tutorial[Helm-based Operators].
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
** xref:../operators/operator_sdk/osdk-about.adoc#osdk-about[Use Operator SDK to build, test, and deploy an Operator].
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
** xref:../operators/user/olm-installing-operators-in-namespace.adoc#olm-installing-operators-in-namespace[Install and subscribe an Operator to your namespace].
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
@@ -71,4 +62,4 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[id="operators-overview-next-steps"]
|
||||
== Next steps
|
||||
|
||||
To understand more about Operators, see xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[What are Operators?]
|
||||
* xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[What are Operators?]
|
||||
|
||||
@@ -167,7 +167,6 @@ In {product-title}, OLM functionality is provided across a set of cluster Operat
|
||||
[id="cluster-operators-ref-olm-addtl-resources"]
|
||||
=== Additional resources
|
||||
* xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Understanding Operator Lifecycle Manager (OLM)]
|
||||
* xref:../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-control-compat_osdk-working-bundle-images[Controlling Operator compatibility with {product-title} versions]
|
||||
|
||||
include::modules/olmv1-clusteroperator.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
../../../_attributes/
|
||||
@@ -1 +0,0 @@
|
||||
../../images
|
||||
@@ -1 +0,0 @@
|
||||
../../modules
|
||||
@@ -1,12 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-cr-status"]
|
||||
= Custom resource status management
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-cr-mgmt
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-cr-status-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-cr-status-manual.adoc[leveloffset=+1]
|
||||
@@ -1,19 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-inside-operator"]
|
||||
= Using Ansible inside an Operator
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-inside-operator
|
||||
|
||||
toc::[]
|
||||
|
||||
After you are familiar with xref:../../../operators/operator_sdk/ansible/osdk-ansible-k8s-collection.adoc#osdk-ansible-k8s-collection[using the Kubernetes Collection for Ansible locally], you can trigger the same Ansible logic inside of an Operator when a custom resource (CR) changes. This example maps an Ansible role to a specific Kubernetes resource that the Operator watches. This mapping is done in the `watches.yaml` file.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-custom-resource-files.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-inside-operator-local.adoc[leveloffset=+1]
|
||||
include::modules/osdk-run-deployment.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-inside-operator-logs.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-inside-operator-logs-view.adoc[leveloffset=+2]
|
||||
include::modules/osdk-ansible-inside-operator-logs-full-result.adoc[leveloffset=+2]
|
||||
include::modules/osdk-ansible-inside-operator-logs-verbose.adoc[leveloffset=+2]
|
||||
@@ -1,23 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-k8s-collection"]
|
||||
= Kubernetes Collection for Ansible
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-k8s-collection
|
||||
|
||||
toc::[]
|
||||
|
||||
To manage the lifecycle of your application on Kubernetes using Ansible, you can use the link:https://galaxy.ansible.com/community/kubernetes[Kubernetes Collection for Ansible]. This collection of Ansible modules allows a developer to either leverage their existing Kubernetes resource files written in YAML or express the lifecycle management in native Ansible.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
One of the biggest benefits of using Ansible in conjunction with existing Kubernetes resource files is the ability to use Jinja templating so that you can customize resources with the simplicity of a few variables in Ansible.
|
||||
|
||||
This section goes into detail on usage of the Kubernetes Collection. To get started, install the collection on your local workstation and test it using a playbook before moving on to using it within an Operator.
|
||||
|
||||
include::modules/osdk-ansible-k8s-install.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-k8s-local.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-ansible-k8s-collection-next-steps"]
|
||||
== Next steps
|
||||
|
||||
* See xref:../../../operators/operator_sdk/ansible/osdk-ansible-inside-operator.adoc#osdk-ansible-inside-operator[Using Ansible inside an Operator] for details on triggering your custom Ansible logic inside of an Operator when a custom resource (CR) changes.
|
||||
@@ -1,13 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-project-layout"]
|
||||
= Project layout for Ansible-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-project-layout
|
||||
|
||||
toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-project-layout.adoc[leveloffset=+1]
|
||||
@@ -1,29 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-quickstart"]
|
||||
= Getting started with Operator SDK for Ansible-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-quickstart
|
||||
|
||||
toc::[]
|
||||
|
||||
// This assembly is currently excluded from the OSD and ROSA docs, because it requires cluster-admin permissions.
|
||||
|
||||
The Operator SDK includes options for generating an Operator project that leverages existing Ansible playbooks and modules to deploy Kubernetes resources as a unified application, without having to write any Go code.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
To demonstrate the basics of setting up and running an link:https://docs.ansible.com/ansible/latest/index.html[Ansible]-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Ansible-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
|
||||
include::modules/osdk-quickstart.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-ansible-quickstart-next-steps"]
|
||||
== Next steps
|
||||
|
||||
* See xref:../../../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-ansible-tutorial[Operator SDK tutorial for Ansible-based Operators] for a more in-depth walkthrough on building an Ansible-based Operator.
|
||||
@@ -1,14 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-support"]
|
||||
= Ansible support in Operator SDK
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-support
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-custom-resource-files.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-watches-file.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-extra-variables.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-runner-directory.adoc[leveloffset=+1]
|
||||
@@ -1,93 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-tutorial"]
|
||||
= Operator SDK tutorial for Ansible-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-tutorial
|
||||
|
||||
toc::[]
|
||||
|
||||
Operator developers can take advantage of link:https://docs.ansible.com/ansible/latest/index.html[Ansible] support in the Operator SDK to build an example Ansible-based Operator for Memcached, a distributed key-value store, and manage its lifecycle. This tutorial walks through the following process:
|
||||
|
||||
* Create a Memcached deployment
|
||||
* Ensure that the deployment size is the same as specified by the `Memcached` custom resource (CR) spec
|
||||
* Update the `Memcached` CR status using the status writer with the names of the `memcached` pods
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished by using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
|
||||
Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than xref:../../../operators/operator_sdk/ansible/osdk-ansible-quickstart.adoc#osdk-ansible-quickstart[Getting started with Operator SDK for Ansible-based Operators].
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-ansible-quickstart[Getting started with Operator SDK for Ansible-based Operators] in the OpenShift Container Platform documentation.
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
// TODO-HCP remove line 44 and 46 ifndef conditions for HCP after cli_tools book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-create-project.adoc[leveloffset=+1]
|
||||
include::modules/osdk-project-file.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-ansible-create-api.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-modify-manager.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/osdk-run-proxy.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/osdk-run-operator.adoc[leveloffset=+1]
|
||||
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-ansible-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-ansible-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
include::modules/osdk-run-locally.adoc[leveloffset=+2]
|
||||
include::modules/osdk-run-deployment.adoc[leveloffset=+2]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
[id="osdk-bundle-deploy-olm_{context}"]
|
||||
=== Bundling an Operator and deploying with Operator Lifecycle Manager
|
||||
|
||||
include::modules/osdk-bundle-operator.adoc[leveloffset=+3]
|
||||
include::modules/osdk-deploy-olm.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/osdk-create-cr.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
[id="osdk-ansible-tutorial-addtl-resources"]
|
||||
== Additional resources
|
||||
|
||||
* See xref:../../../operators/operator_sdk/ansible/osdk-ansible-project-layout.adoc#osdk-ansible-project-layout[Project layout for Ansible-based Operators] to learn about the directory structures created by the Operator SDK.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
// TODO-HCP remove line 88 and 91 ifndef conditions for HCP after networking book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured]
|
||||
endif::openshift-rosa-hcp[]
|
||||
, administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
@@ -1,22 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ansible-updating-projects"]
|
||||
= Updating projects for newer Operator SDK versions
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ansible-updating-projects
|
||||
|
||||
toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
|
||||
|
||||
[id="additional-resources_osdk-ansible-upgrading-projects"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-ansible-updating-projects[Updating Ansible-based Operator projects for Operator SDK 1.36.1] ({product-title} 4.17)
|
||||
* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
|
||||
@@ -1 +0,0 @@
|
||||
../../../snippets/
|
||||
@@ -1 +0,0 @@
|
||||
../../_attributes/
|
||||
@@ -1 +0,0 @@
|
||||
../images
|
||||
@@ -1 +0,0 @@
|
||||
../modules
|
||||
@@ -1,13 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-golang-project-layout"]
|
||||
= Project layout for Go-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-golang-project-layout
|
||||
|
||||
toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-golang-project-layout.adoc[leveloffset=+1]
|
||||
@@ -1,27 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-golang-quickstart"]
|
||||
= Getting started with Operator SDK for Go-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-golang-quickstart
|
||||
|
||||
toc::[]
|
||||
|
||||
// This assembly is currently excluded from the OSD and ROSA docs, because it requires cluster-admin permissions.
|
||||
|
||||
To demonstrate the basics of setting up and running a Go-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Go-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
|
||||
include::modules/osdk-quickstart.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-golang-quickstart-next-steps"]
|
||||
== Next steps
|
||||
|
||||
* See xref:../../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-golang-tutorial[Operator SDK tutorial for Go-based Operators] for a more in-depth walkthrough on building a Go-based Operator.
|
||||
@@ -1,103 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-golang-tutorial"]
|
||||
= Operator SDK tutorial for Go-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-golang-tutorial
|
||||
|
||||
toc::[]
|
||||
|
||||
Operator developers can take advantage of Go programming language support in the Operator SDK to build an example Go-based Operator for Memcached, a distributed key-value store, and manage its lifecycle.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
|
||||
Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than xref:../../../operators/operator_sdk/golang/osdk-golang-quickstart.adoc#osdk-golang-quickstart[Getting started with Operator SDK for Go-based Operators].
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-golang-quickstart[Getting started with Operator SDK for Go-based Operators] in the OpenShift Container Platform documentation.
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
// TODO-HCP remove conditions ifndef line 40 & 42 for HCP after cli_tools book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-create-project.adoc[leveloffset=+1]
|
||||
include::modules/osdk-project-file.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-manager.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-multi-group-apis.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-golang-create-api-controller.adoc[leveloffset=+1]
|
||||
include::modules/osdk-golang-define-api.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-generate-crd.adoc[leveloffset=+2]
|
||||
include::modules/osdk-about-openapi-validation.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/osdk-golang-implement-controller.adoc[leveloffset=+1]
|
||||
|
||||
The next subsections explain how the controller in the example implementation watches resources and how the reconcile loop is triggered. You can skip these subsections to go directly to xref:../../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-run-operator_osdk-golang-tutorial[Running the Operator].
|
||||
|
||||
include::modules/osdk-golang-controller-resources.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-controller-configs.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-controller-reconcile-loop.adoc[leveloffset=+2]
|
||||
include::modules/osdk-golang-controller-rbac-markers.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-run-proxy.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/osdk-run-operator.adoc[leveloffset=+1]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-golang-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-golang-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
include::modules/osdk-run-locally.adoc[leveloffset=+2]
|
||||
include::modules/osdk-run-deployment.adoc[leveloffset=+2]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
[id="osdk-bundle-deploy-olm_{context}"]
|
||||
=== Bundling an Operator and deploying with Operator Lifecycle Manager
|
||||
|
||||
include::modules/osdk-bundle-operator.adoc[leveloffset=+3]
|
||||
include::modules/osdk-deploy-olm.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/osdk-create-cr.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-golang-tutorial-addtl-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* See xref:../../../operators/operator_sdk/golang/osdk-golang-project-layout.adoc#osdk-golang-project-layout[Project layout for Go-based Operators] to learn about the directory structures created by the Operator SDK.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
// TODO-HCP remove line 97 and 99 conditions and add the HCP condition to line 92 and 98 for HCP after networking book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured],
|
||||
endif::openshift-rosa-hcp[]
|
||||
administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-golang-updating-projects"]
|
||||
= Updating Go-based Operator projects for newer Operator SDK versions
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-golang-updating-projects
|
||||
|
||||
toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
|
||||
|
||||
[id="additional-resources_osdk-upgrading-projects-golang"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-golang-updating-projects[Updating Go-based projects for Operator SDK 1.36.1] ({product-title} 4.17)
|
||||
* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
|
||||
@@ -1 +0,0 @@
|
||||
../../../snippets/
|
||||
@@ -1 +0,0 @@
|
||||
../../_attributes/
|
||||
@@ -1 +0,0 @@
|
||||
../../images
|
||||
@@ -1 +0,0 @@
|
||||
../../modules
|
||||
@@ -1,13 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-helm-project-layout"]
|
||||
= Project layout for Helm-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-helm-project-layout
|
||||
|
||||
toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-helm-project-layout.adoc[leveloffset=+1]
|
||||
@@ -1,29 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-helm-quickstart"]
|
||||
= Getting started with Operator SDK for Helm-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-helm-quickstart
|
||||
|
||||
toc::[]
|
||||
|
||||
// This assembly is currently excluded from the OSD and ROSA docs, because it requires cluster-admin permissions.
|
||||
|
||||
The Operator SDK includes options for generating an Operator project that leverages existing link:https://helm.sh/docs/[Helm] charts to deploy Kubernetes resources as a unified application, without having to write any Go code.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
To demonstrate the basics of setting up and running an link:https://helm.sh/docs/[Helm]-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Helm-based Operator for Nginx and deploy it to a cluster.
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
|
||||
include::modules/osdk-quickstart.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-helm-quickstart-next-steps"]
|
||||
== Next steps
|
||||
|
||||
* See xref:../../../operators/operator_sdk/helm/osdk-helm-tutorial.adoc#osdk-helm-tutorial[Operator SDK tutorial for Helm-based Operators] for a more in-depth walkthrough on building a Helm-based Operator.
|
||||
@@ -1,11 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-helm-support"]
|
||||
= Helm support in Operator SDK
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-helm-support
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-helm-charts.adoc[leveloffset=+1]
|
||||
@@ -1,96 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-helm-tutorial"]
|
||||
= Operator SDK tutorial for Helm-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-helm-tutorial
|
||||
|
||||
toc::[]
|
||||
|
||||
Operator developers can take advantage of link:https://helm.sh/docs/[Helm] support in the Operator SDK to build an example Helm-based Operator for Nginx and manage its lifecycle. This tutorial walks through the following process:
|
||||
|
||||
* Create a Nginx deployment
|
||||
* Ensure that the deployment size is the same as specified by the `Nginx` custom resource (CR) spec
|
||||
* Update the `Nginx` CR status using the status writer with the names of the `nginx` pods
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
|
||||
Operator Lifecycle Manager (OLM):: Installation, upgrade, and role-based access control (RBAC) of Operators on a cluster
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than xref:../../../operators/operator_sdk/helm/osdk-helm-quickstart.adoc#osdk-helm-quickstart[Getting started with Operator SDK for Helm-based Operators].
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// The "Getting started" quickstarts require cluster-admin and are therefore only available in OCP.
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[NOTE]
|
||||
====
|
||||
This tutorial goes into greater detail than link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-helm-quickstart[Getting started with Operator SDK for Helm-based Operators] in the OpenShift Container Platform documentation.
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[Installing the Operator SDK CLI]
|
||||
// TODO-HCP remove line 44 and 46 ifndef conditions for HCP after cli_tools book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../../cli_reference/openshift_cli/getting-started-cli.adoc#getting-started-cli[Getting started with the OpenShift CLI]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-create-project.adoc[leveloffset=+1]
|
||||
include::modules/osdk-helm-existing-chart.adoc[leveloffset=+2]
|
||||
include::modules/osdk-project-file.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-helm-logic.adoc[leveloffset=+1]
|
||||
include::modules/osdk-helm-sample-chart.adoc[leveloffset=+2]
|
||||
include::modules/osdk-helm-modify-cr.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-run-proxy.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
include::modules/osdk-run-operator.adoc[leveloffset=+1]
|
||||
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-locally_osdk-helm-tutorial[Running locally outside the cluster] (OpenShift Container Platform documentation)
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-run-deployment_osdk-helm-tutorial[Running as a deployment on the cluster] (OpenShift Container Platform documentation)
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// In OSD/ROSA, the only applicable option for running the Operator is to bundle and deploy with OLM.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
include::modules/osdk-run-locally.adoc[leveloffset=+2]
|
||||
include::modules/osdk-run-deployment.adoc[leveloffset=+2]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
[id="osdk-bundle-deploy-olm_{context}"]
|
||||
=== Bundling an Operator and deploying with Operator Lifecycle Manager
|
||||
|
||||
include::modules/osdk-bundle-operator.adoc[leveloffset=+3]
|
||||
include::modules/osdk-deploy-olm.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/osdk-create-cr.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-helm-tutorial-addtl-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* See xref:../../../operators/operator_sdk/helm/osdk-helm-project-layout.adoc#osdk-helm-project-layout[Project layout for Helm-based Operators] to learn about the directory structures created by the Operator SDK.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[cluster-wide egress proxy is configured], cluster administrators can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
// TODO-HCP remove line 92 and 94 ifndef conditions for HCP after networking book is migrated ad put the hcp condition back on line 90 and 95
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured], administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-rosa-hcp[]
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-helm-updating-projects"]
|
||||
= Updating Helm-based projects for newer Operator SDK versions
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-helm-updating-projects
|
||||
|
||||
toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-1361-to-138.adoc[leveloffset=+1]
|
||||
|
||||
[id="additional-resources_osdk-helm-upgrading-projects"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/operators/index#osdk-upgrading-projects_osdk-helm-updating-projects[Updating Helm-based Operator projects for Operator SDK 1.36.1] ({product-title} 4.17)
|
||||
* xref:../../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
|
||||
@@ -1 +0,0 @@
|
||||
../../../snippets/
|
||||
@@ -1,64 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-about"]
|
||||
= About the Operator SDK
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-about
|
||||
|
||||
toc::[]
|
||||
|
||||
The link:https://operatorframework.io/[Operator Framework] is an open source toolkit to manage Kubernetes native applications, called _Operators_, in an effective, automated, and scalable way. Operators take advantage of Kubernetes extensibility to deliver the automation advantages of cloud services, like provisioning, scaling, and backup and restore, while being able to run anywhere that Kubernetes can run.
|
||||
|
||||
Operators make it easy to manage complex, stateful applications on top of Kubernetes. However, writing an Operator today can be difficult because of challenges such as using low-level APIs, writing boilerplate, and a lack of modularity, which leads to duplication.
|
||||
|
||||
The Operator SDK, a component of the Operator Framework, provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
**Why use the Operator SDK?**
|
||||
|
||||
The Operator SDK simplifies this process of building Kubernetes-native applications, which can require deep, application-specific operational knowledge. The Operator SDK not only lowers that barrier, but it also helps reduce the amount of boilerplate code required for many common management capabilities, such as metering or monitoring.
|
||||
|
||||
The Operator SDK is a framework that uses the link:https://github.com/kubernetes-sigs/controller-runtime[controller-runtime] library to make writing Operators easier by providing the following features:
|
||||
|
||||
- High-level APIs and abstractions to write the operational logic more intuitively
|
||||
- Tools for scaffolding and code generation to quickly bootstrap a new project
|
||||
- Integration with Operator Lifecycle Manager (OLM) to streamline packaging, installing, and running Operators on a cluster
|
||||
- Extensions to cover common Operator use cases
|
||||
- Metrics set up automatically in any generated Go-based Operator for use on clusters where the Prometheus Operator is deployed
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
Operator authors with cluster administrator access to a Kubernetes-based cluster (such as {product-title})
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
Operator authors with dedicated-admin access to {product-title}
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}.
|
||||
====
|
||||
|
||||
[id="osdk-about-what-are-operators"]
|
||||
== What are Operators?
|
||||
|
||||
For an overview about basic Operator concepts and terminology, see xref:../../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Understanding Operators].
|
||||
|
||||
include::modules/osdk-workflow.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-about-addtl-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
- link:https://redhat-connect.gitbook.io/certified-operator-guide/[Certified Operator Build Guide]
|
||||
|
||||
ifdef::openshift-origin[]
|
||||
[id="osdk-about-getting-involved"]
|
||||
== Getting involved
|
||||
|
||||
This guide provides an effective demonstration of the value of the Operator Framework for building and managing Operators, but it is limited in scope. The Operator Framework and its components are open source, so visit each project individually and learn what else you can do:
|
||||
|
||||
link:https://github.com/operator-framework[*github.com/operator-framework*]
|
||||
|
||||
If you want to discuss your experience, have questions, or want to get involved, join the link:https://groups.google.com/forum/#!forum/operator-framework[Operator Framework mailing list].
|
||||
endif::[]
|
||||
@@ -1,30 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-bundle-validate"]
|
||||
= Validating Operator bundles
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-bundle-validate
|
||||
|
||||
toc::[]
|
||||
|
||||
As an Operator author, you can run the `bundle validate` command in the Operator SDK to validate the content and format of an Operator bundle. You can run the command on a remote Operator bundle image or a local Operator bundle directory.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-bundle-validate-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-bundle-validate-tests.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Bundle format]
|
||||
|
||||
include::modules/osdk-bundle-validate-run.adoc[leveloffset=+1]
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
include::modules/osdk-multi-arch-validate.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/operator_sdk/osdk-multi-arch-support.adoc#osdk-multi-platform-support[Configuring Operator projects for multi-platform support]
|
||||
endif::[]
|
||||
@@ -1,70 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-cli-ref"]
|
||||
= Operator SDK CLI reference
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-cli-ref
|
||||
|
||||
toc::[]
|
||||
|
||||
The Operator SDK command-line interface (CLI) is a development kit designed to make writing Operators easier.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
.Operator SDK CLI syntax
|
||||
[source,terminal]
|
||||
----
|
||||
$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
|
||||
----
|
||||
|
||||
Operator authors with cluster administrator access to a Kubernetes-based cluster (such as {product-title}) can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
|
||||
|
||||
include::modules/osdk-cli-ref-bundle.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-cleanup.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-completion.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-create.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-generate.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-generate-bundle.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-bundle-operator_osdk-working-bundle-images[Bundling an Operator] for a full procedure that includes using the `make bundle` command to call the `generate bundle` subcommand.
|
||||
|
||||
include::modules/osdk-cli-ref-generate-kustomize.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-cli-ref-init.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-run.adoc[leveloffset=+1]
|
||||
include::modules/osdk-cli-ref-run-bundle.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/understanding/olm/olm-understanding-operatorgroups.adoc#olm-operatorgroups-membership_olm-understanding-operatorgroups[Operator group membership] for details on possible install modes.
|
||||
* xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
|
||||
// TODO-HCP remove line 45 and 47 ifndef conditions for HCP after Authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-cli-ref-run-bundle-upgrade.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
|
||||
// TODO-HCP remove line 55 and 57 ifndef conditions for HCP after Authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-cli-ref-scorecard.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/operator_sdk/osdk-scorecard.adoc#osdk-scorecard[Validating Operators using the scorecard tool] for details about running the scorecard tool.
|
||||
* xref:../../operators/operator_sdk/osdk-complying-with-psa.adoc#osdk-complying-with-psa[Complying with pod security admission]
|
||||
// TODO-HCP remove line 67 and 69 ifndef conditions for HCP after Authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -1,48 +0,0 @@
|
||||
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-complying-with-psa"]
|
||||
= Complying with pod security admission
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-complying-with-psa
|
||||
|
||||
toc::[]
|
||||
|
||||
_Pod security admission_ is an implementation of the link:https://kubernetes.io/docs/concepts/security/pod-security-standards/[Kubernetes pod security standards]. link:https://kubernetes.io/docs/concepts/security/pod-security-admission/[Pod security admission] restricts the behavior of pods. Pods that do not comply with the pod security admission defined globally or at the namespace level are not admitted to the cluster and cannot run.
|
||||
|
||||
If your Operator project does not require escalated permissions to run, you can ensure your workloads run in namespaces set to the `restricted` pod security level. If your Operator project requires escalated permissions to run, you must set the following security context configurations:
|
||||
|
||||
* The allowed pod security admission level for the Operator's namespace
|
||||
* The allowed security context constraints (SCC) for the workload's service account
|
||||
// TODO-HCP remove line 17 and 19 ifndef conditions for HCP after authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
For more information, see xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission].
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
// About pod security admission
|
||||
include::modules/security-context-constraints-psa-about.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/security-context-constraints-psa-synchronization.adoc[leveloffset=+1]
|
||||
|
||||
// Pod security admission synchronization namespace exclusions
|
||||
include::modules/security-context-constraints-psa-sync-exclusions.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-ensuring-operator-workloads-run-restricted-psa.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
// TODO-HCP remove line 36 and 38 ifndef conditions for HCP after authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/managing-security-context-constraints.adoc#managing-security-context-constraints[Managing security context constraints]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-managing-psa-for-operators-with-escalated-permissions.adoc[leveloffset=+1]
|
||||
|
||||
[id="osdk-complying-with-psa-additional-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
// TODO-HCP remove line 46 and 48 ifndef conditions for HCP after authentication book is migrated
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -1,99 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-generating-csvs"]
|
||||
= Defining cluster service versions (CSVs)
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-generating-csvs
|
||||
|
||||
toc::[]
|
||||
|
||||
A _cluster service version_ (CSV), defined by a `ClusterServiceVersion` object, is a YAML manifest created from Operator metadata that assists Operator Lifecycle Manager (OLM) in running the Operator in a cluster. It is the metadata that accompanies an Operator container image, used to populate user interfaces with information such as its logo, description, and version. It is also a source of technical information that is required to run the Operator, like the RBAC rules it requires and which custom resources (CRs) it manages or depends on.
|
||||
|
||||
The Operator SDK includes the CSV generator to generate a CSV for the current Operator project, customized using information contained in YAML manifests and Operator source files.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
A CSV-generating command removes the responsibility of Operator authors having in-depth OLM knowledge in order for their Operator to interact with OLM or publish metadata to the Catalog Registry. Further, because the CSV spec will likely change over time as new Kubernetes and OLM features are implemented, the Operator SDK is equipped to easily extend its update system to handle new CSV features going forward.
|
||||
|
||||
include::modules/osdk-how-csv-gen-works.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-bundle-operator_osdk-working-bundle-images[Bundling an Operator] for a full procedure that includes generating a bundle and CSV.
|
||||
|
||||
include::modules/osdk-csv-bundle-files.adoc[leveloffset=+2]
|
||||
include::modules/osdk-csv-ver.adoc[leveloffset=+2]
|
||||
|
||||
|
||||
include::modules/osdk-manually-defined-csv-fields.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm-what-operators-are.adoc#olm-maturity-model_olm-what-operators-are[Operator maturity model]
|
||||
|
||||
include::modules/osdk-csv-manual-annotations.adoc[leveloffset=+1]
|
||||
include::modules/osdk-csv-annotations-infra.adoc[leveloffset=+2]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-enabling-operator-for-restricted-network_osdk-generating-csvs[Enabling your Operator for restricted network environments] (disconnected mode)
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* xref:../../installing/overview/installing-fips.adoc#installing-fips[Support for FIPS cryptography]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
include::modules/osdk-csv-annotations-dep.adoc[leveloffset=+2]
|
||||
include::modules/osdk-csv-annotations-other.adoc[leveloffset=+2]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-crds-templates_osdk-generating-csvs[CRD templates]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-init-resource_osdk-generating-csvs[Initializing required custom resources]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-suggested-namespace_osdk-generating-csvs[Setting a suggested namespace]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-suggested-namespace-default-node_osdk-generating-csvs[Setting a suggested namespace with default node selector]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-hiding-internal-objects_osdk-generating-csvs[Hiding internal objects]
|
||||
|
||||
include::modules/olm-enabling-operator-restricted-network.adoc[leveloffset=+1]
|
||||
include::modules/olm-enabling-operator-for-multi-arch.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See the link:https://docs.docker.com/registry/spec/manifest-v2-2/#manifest-list[Image Manifest V 2, Schema 2] specification for more information on manifest lists.
|
||||
|
||||
include::modules/olm-arch-os-support.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-suggested-namespace.adoc[leveloffset=+1]
|
||||
include::modules/osdk-suggested-namespace-node-selector.adoc[leveloffset=+1]
|
||||
include::modules/osdk-operatorconditions.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm/olm-operatorconditions.adoc#olm-operatorconditions[Operator conditions]
|
||||
|
||||
include::modules/olm-defining-csv-webhooks.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
// This xref points to a topic that is not currently included in the OSD and ROSA docs.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* xref:../../architecture/admission-plug-ins.adoc#admission-webhook-types_admission-plug-ins[Types of webhook admission plugins]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* Kubernetes documentation:
|
||||
** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook[Validating admission webhooks]
|
||||
** link:https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook[Mutating admission webhooks]
|
||||
** link:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion[Conversion webhooks]
|
||||
|
||||
include::modules/olm-webhook-considerations.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-crds.adoc[leveloffset=+1]
|
||||
include::modules/osdk-owned-crds.adoc[leveloffset=+2]
|
||||
include::modules/osdk-required-crds.adoc[leveloffset=+2]
|
||||
include::modules/olm-dependency-resolution-crd-upgrades.adoc[leveloffset=+2]
|
||||
include::modules/olm-adding-new-crd-version.adoc[leveloffset=+3]
|
||||
include::modules/olm-removing-crd-version.adoc[leveloffset=+3]
|
||||
include::modules/osdk-crd-templates.adoc[leveloffset=+2]
|
||||
include::modules/osdk-hiding-internal-objects.adoc[leveloffset=+2]
|
||||
include::modules/osdk-init-resource.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/osdk-apiservices.adoc[leveloffset=+1]
|
||||
@@ -1,22 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-ha-sno"]
|
||||
= High-availability or single-node cluster detection and support
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-ha-sno
|
||||
|
||||
toc::[]
|
||||
|
||||
// OSD/ROSA don't support single-node clusters, but these Operator authors still need to know how to handle this configuration for their Operators to work correctly in OCP.
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
To ensure that your Operator runs well on both high-availability (HA) and non-HA modes in OpenShift Container Platform clusters, you can use the Operator SDK to detect the cluster's infrastructure topology and set the resource requirements to fit the cluster's topology.
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
// Not using {product-title} here, because HA mode and non-HA mode are specific to OCP and should be spelled out this way in other distros.
|
||||
An OpenShift Container Platform cluster can be configured in high-availability (HA) mode, which uses multiple nodes, or in non-HA mode, which uses a single node. A single-node cluster, also known as {sno}, is likely to have more conservative resource constraints. Therefore, it is important that Operators installed on a single-node cluster can adjust accordingly and still run well.
|
||||
|
||||
By accessing the cluster high-availability mode API provided in {product-title}, Operator authors can use the Operator SDK to enable their Operator to detect a cluster's infrastructure topology, either HA or non-HA mode. Custom Operator logic can be developed that uses the detected cluster topology to automatically switch the resource requirements, both for the Operator and for any Operands or workloads it manages, to a profile that best fits the topology.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ha-sno-api.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ha-sno-api-examples.adoc[leveloffset=+1]
|
||||
@@ -1,28 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-installing-cli"]
|
||||
= Installing the Operator SDK CLI
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-installing-cli
|
||||
|
||||
toc::[]
|
||||
|
||||
The Operator SDK provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator. You can install the Operator SDK CLI on your workstation so that you are prepared to start authoring your own Operators.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
Operator authors with cluster administrator access to a Kubernetes-based cluster, such as {product-title},
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
Operator authors with dedicated-admin access to {product-title}
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}.
|
||||
====
|
||||
|
||||
include::modules/osdk-installing-cli-linux-macos.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/osdk-installing-cli-macos.adoc[leveloffset=+1]
|
||||
@@ -1,21 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-leader-election"]
|
||||
= Configuring leader election
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-leader-election
|
||||
|
||||
toc::[]
|
||||
|
||||
During the lifecycle of an Operator, it is possible that there may be more than one instance running at any given time, for example when rolling out an upgrade for the Operator. In such a scenario, it is necessary to avoid contention between multiple Operator instances using leader election. This ensures only one leader instance handles the reconciliation while the other instances are inactive but ready to take over when the leader steps down.
|
||||
|
||||
There are two different leader election implementations to choose from, each with its own tradeoff:
|
||||
|
||||
Leader-for-life:: The leader pod only gives up leadership, using garbage collection, when it is deleted. This implementation precludes the possibility of two instances mistakenly running as leaders, a state also known as split brain. However, this method can be subject to a delay in electing a new leader. For example, when the leader pod is on an unresponsive or partitioned node, you can specify `node.kubernetes.io/unreachable` and `node.kubernetes.io/not-ready` tolerations on the leader pod and use the `tolerationSeconds` value to dictate how long it takes for the leader pod to be deleted from the node and step down. These tolerations are added to the pod by default on admission with a `tolerationSeconds` value of 5 minutes. See the link:https://godoc.org/github.com/operator-framework/operator-sdk/pkg/leader[Leader-for-life] Go documentation for more.
|
||||
|
||||
Leader-with-lease:: The leader pod periodically renews the leader lease and gives up leadership when it cannot renew the lease. This implementation allows for a faster transition to a new leader when the existing leader is isolated, but there is a possibility of split brain in link:https://github.com/kubernetes/client-go/blob/30b06a83d67458700a5378239df6b96948cb9160/tools/leaderelection/leaderelection.go#L21-L24[certain situations]. See the link:https://godoc.org/github.com/kubernetes-sigs/controller-runtime/pkg/leaderelection[Leader-with-lease] Go documentation for more.
|
||||
|
||||
By default, the Operator SDK enables the Leader-for-life implementation. Consult the related Go documentation for both approaches to consider the trade-offs that make sense for your use case.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-leader-election-types.adoc[leveloffset=+1]
|
||||
@@ -1,23 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-migrating-to-v0-1-0"]
|
||||
= Migrating to Operator SDK v0.1.0
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-migrating-to-v0-1-0
|
||||
|
||||
toc::[]
|
||||
|
||||
This guide describes how to migrate an Operator project built using Operator SDK v0.0.x to the project structure required by link:https://github.com/operator-framework/operator-sdk/releases[Operator SDK v0.1.0].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
The recommended method for migrating your project is to:
|
||||
|
||||
. Initialize a new v0.1.0 project.
|
||||
. Copy your code into the new project.
|
||||
. Modify the new project as described for v0.1.0.
|
||||
|
||||
This guide uses the `memcached-operator`, the example project from xref:../../operators/operator_sdk/osdk-about.adoc#osdk-about[the Operator SDK], to illustrate the migration steps. See the link:https://github.com/operator-framework/operator-sdk-samples/tree/aa15bd278eec0959595e0a0a7282a26055d7f9d6/memcached-operator[v0.0.7 memcached-operator] and link:https://github.com/operator-framework/operator-sdk-samples/tree/4c6934448684a6953ece4d3d9f3f77494b1c125e/memcached-operator[v0.1.0 memcached-operator] project structures for pre- and post-migration examples, respectively.
|
||||
|
||||
include::modules/creating-new-osdk-v0-1-0-project.adoc[leveloffset=+1]
|
||||
include::modules/migrating-custom-types-pkg-apis.adoc[leveloffset=+1]
|
||||
include::modules/migrating-reconcile-code.adoc[leveloffset=+1]
|
||||
@@ -1,43 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-monitoring-prometheus"]
|
||||
= Configuring built-in monitoring with Prometheus
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-monitoring-prometheus
|
||||
|
||||
toc::[]
|
||||
|
||||
// Dedicated-admins in OSD and ROSA don't have the permissions to complete the procedures in this assembly. Also, the procedures use the default Prometheus Operator in the openshift-monitoring project, which OSD/ROSA customers should not use.
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
This guide describes the built-in monitoring support provided by the Operator SDK using the Prometheus Operator and details usage for authors of Go-based and Ansible-based Operators.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-monitoring-prometheus-operator-support.adoc[leveloffset=+1]
|
||||
include::modules/osdk-monitoring-custom-metrics.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-metrics.adoc[leveloffset=+1]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
// Since OSD/ROSA dedicated-admins can't do the procedures in this assembly, point to the OCP docs.
|
||||
The Operator SDK provides built-in monitoring support using the Prometheus Operator, which you can use to expose custom metrics for your Operator.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
By default, {product-title} provides a Prometheus Operator in the `openshift-user-workload-monitoring` project. You should use this Prometheus instance to monitor user workloads in {product-title}.
|
||||
|
||||
Do not use the Prometheus Operator in the `openshift-monitoring` project. Red Hat Site Reliability Engineers (SRE) use this Prometheus instance to monitor core cluster components.
|
||||
====
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-monitoring-custom-metrics_osdk-monitoring-prometheus[Exposing custom metrics for Go-based Operators] (OpenShift Container Platform documentation)
|
||||
* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html-single/operators/index#osdk-ansible-metrics_osdk-monitoring-prometheus[Exposing custom metrics for Ansible-based Operators] (OpenShift Container Platform documentation)
|
||||
// TODO-HCP remove line 39 and 41 ifndef conditions for HCP after Observability book is migrated and add back HCP condition to line 41 and 21
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../observability/monitoring/monitoring-overview.adoc#understanding-the-monitoring-stack_monitoring-overview[Understanding the monitoring stack] in {product-title}
|
||||
endif::openshift-rosa-hcp[]
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-multi-platform-support"]
|
||||
= Configuring Operator projects for multi-platform support
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-multi-arch
|
||||
|
||||
toc::[]
|
||||
|
||||
Operator projects that support multiple architectures and operating systems, or _platforms_, can run on more Kubernetes and {product-title} clusters than Operator projects that support only a single platform. Example architectures include `amd64`, `arm64`, `ppc64le`, and `s390x`. Example operating systems include Linux and Windows.
|
||||
|
||||
Perform the following actions to ensure your Operator project can run on multiple {product-title} platforms:
|
||||
|
||||
* Build a manifest list that specifies the platforms that your Operator supports.
|
||||
* Set your Operator's node affinity to support multi-architecture compute machines.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-multi-arch-building-images.adoc[leveloffset=+1]
|
||||
include::modules/osdk-multi-arch-node-affinity.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity[Controlling pod placement on nodes using node affinity rules]
|
||||
* xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#olm-overriding-operator-pod-affinity_nodes-scheduler-node-affinity[Using node affinity to control where an Operator is installed]
|
||||
* xref:../../post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-configuration.adoc#post-install-multi-architecture-configuration[About clusters with multi-architecture compute machines]
|
||||
|
||||
include::modules/osdk-multi-arch-node-reqs.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-configuring-required_nodes-scheduler-node-affinity[Configuring a required node affinity rule]
|
||||
* xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-example_nodes-scheduler-node-affinity[Sample node affinity rules]
|
||||
|
||||
include::modules/osdk-multi-arch-node-preference.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-configuring-preferred_nodes-scheduler-node-affinity[Configuring a preferred node affinity rule]
|
||||
|
||||
[id="next-steps_osdk-multi-arch-support"]
|
||||
== Next steps
|
||||
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-enabling-operator-for-multi-arch_osdk-generating-csvs[Label the platforms your Operator supports for Operator Lifecycle Manager (OLM)]
|
||||
* Bundle your Operator and Deploy with OLM
|
||||
** xref:../../operators/operator_sdk/golang/osdk-golang-tutorial.adoc#osdk-bundle-deploy-olm_osdk-golang-tutorial[Go-based Operator projects]
|
||||
** xref:../../operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc#osdk-bundle-deploy-olm_osdk-ansible-tutorial[Ansible-based Operator projects]
|
||||
** xref:../../operators/operator_sdk/helm/osdk-helm-tutorial.html#osdk-bundle-deploy-olm_osdk-helm-tutorial[Helm-based Operator projects]
|
||||
* xref:../../operators/operator_sdk/osdk-bundle-validate.html#osdk-multi-arch-validate_osdk-bundle-validate[Validate your Operator's multi-platform readiness]
|
||||
@@ -1,20 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-pkgman-to-bundle"]
|
||||
= Migrating package manifest projects to bundle format
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-pkgman-to-bundle
|
||||
|
||||
toc::[]
|
||||
|
||||
Support for the legacy _package manifest format_ for Operators is removed in {product-title} 4.8 and later. If you have an Operator project that was initially created using the package manifest format, you can use the Operator SDK to migrate the project to the bundle format. The bundle format is the preferred packaging format for Operator Lifecycle Manager (OLM) starting in {product-title} 4.6.
|
||||
//Consider updating this during the 4.10 to 4.11 version scrub.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-about-pkg-format-migration.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-packaging-format[Operator Framework packaging format]
|
||||
|
||||
include::modules/osdk-migrating-pkgman.adoc[leveloffset=+1]
|
||||
@@ -1,14 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-pruning-utility"]
|
||||
= Object pruning utility for Go-based Operators
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-pruning-utility
|
||||
|
||||
toc::[]
|
||||
|
||||
The `operator-lib` pruning utility lets Go-based Operators clean up, or prune, objects when they are no longer needed. Operator authors can also use the utility to create custom hooks and strategies.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-pruning-utility-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-pruning-utility-config.adoc[leveloffset=+1]
|
||||
@@ -1,23 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-scorecard"]
|
||||
= Validating Operators using the scorecard tool
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-scorecard
|
||||
|
||||
toc::[]
|
||||
|
||||
As an Operator author, you can use the scorecard tool in the Operator SDK to do the following tasks:
|
||||
|
||||
* Validate that your Operator project is free of syntax errors and packaged correctly
|
||||
* Review suggestions about ways you can improve your Operator
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-scorecard-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-config.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-tests.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-run.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-output.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-select-tests.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-parallel.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-custom-tests.adoc[leveloffset=+1]
|
||||
@@ -1,52 +0,0 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="osdk-working-bundle-images"]
|
||||
= Working with bundle images
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: osdk-working-bundle-images
|
||||
|
||||
toc::[]
|
||||
|
||||
You can use the Operator SDK to package, deploy, and upgrade Operators in the bundle format for use on Operator Lifecycle Manager (OLM).
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-bundle-operator.adoc[leveloffset=+1]
|
||||
include::modules/osdk-deploy-olm.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[File-based catalogs] in Operator Framework packaging format
|
||||
* xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs-fb[File-based catalogs] in Managing custom catalogs
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Bundle format]
|
||||
|
||||
include::modules/osdk-publish-catalog.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs] for details on direct usage of the `opm` CLI for more advanced use cases.
|
||||
|
||||
include::modules/osdk-bundle-upgrade-olm.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Traditional Operator installation with OLM]
|
||||
|
||||
include::modules/osdk-control-compat.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://redhat-connect.gitbook.io/certified-operator-guide/ocp-deployment/operator-metadata/bundle-directory/managing-openshift-versions[Managing OpenShift Versions] in the _Certified Operator Build Guide_
|
||||
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators]
|
||||
* xref:../../operators/understanding/olm-rh-catalogs.adoc#olm-rh-catalogs[Red Hat-provided Operator catalogs]
|
||||
|
||||
[id="osdk-working-bundle-images-additional-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* See xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging format] for details on the bundle format.
|
||||
* See xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs] for details on adding bundle images to index images by using the `opm` command.
|
||||
* See xref:../../operators/understanding/olm/olm-workflow.adoc#olm-workflow[Operator Lifecycle Manager workflow] for details on how upgrades work for installed Operators.
|
||||
@@ -6,6 +6,6 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This topic provides a glossary of common terms related to the Operator Framework, including Operator Lifecycle Manager (OLM) and the Operator SDK.
|
||||
This topic provides a glossary of common terms related to the Operator Framework, including Operator Lifecycle Manager (OLM).
|
||||
|
||||
include::snippets/of-terms-snippet.adoc[leveloffset=+0]
|
||||
|
||||
@@ -20,7 +20,6 @@ include::modules/olm-default-install-behavior.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
* xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding Operators to a cluster]
|
||||
* xref:../../operators/understanding/olm/olm-understanding-operatorgroups.adoc#olm-operatorgroups-membership_olm-understanding-operatorgroups[Install modes types]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-suggested-namespace_osdk-generating-csvs[Setting a suggested namespace]
|
||||
|
||||
include::modules/olm-multitenancy-solution.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
@@ -36,4 +35,4 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
Operator Lifecycle Manager (OLM) handles OLM-managed Operators that are installed in the same namespace, meaning their `Subscription` resources are colocated in the same namespace, as related Operators. Even if they are not actually related, OLM considers their states, such as their version and update policy, when any one of them is updated.
|
||||
|
||||
For more information on Operator colocation and using Operator groups effectively, see xref:../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Operator Lifecycle Manager (OLM) -> Multitenancy and Operator colocation].
|
||||
For more information on Operator colocation and using Operator groups effectively, see xref:../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Operator Lifecycle Manager (OLM) -> Multitenancy and Operator colocation].
|
||||
|
||||
@@ -14,8 +14,6 @@ include::modules/olm-operatorhub-architecture.adoc[leveloffset=+1]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource_olm-understanding-olm[Catalog source]
|
||||
* xref:../../operators/operator_sdk/osdk-about.adoc#osdk-about[About the Operator SDK]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-generating-csvs[Defining cluster service versions (CSVs)]
|
||||
* xref:../../operators/understanding/olm/olm-workflow.adoc#olm-upgrades_olm-workflow[Operator installation and upgrade workflow in OLM]
|
||||
* link:https://connect.redhat.com[Red Hat Partner Connect]
|
||||
* link:https://marketplace.redhat.com[Red Hat Marketplace]
|
||||
|
||||
@@ -16,7 +16,6 @@ include::modules/olm-supported-operatorconditions.adoc[leveloffset=+1]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../../operators/admin/olm-managing-operatorconditions.adoc#olm-operatorconditions[Managing Operator conditions]
|
||||
* xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#osdk-operatorconditions_osdk-generating-csvs[Enabling Operator conditions]
|
||||
// The following xrefs point to topics that are not currently included in the OSD/ROSA docs.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* xref:../../../nodes/pods/nodes-pods-configuring.adoc#nodes-pods-configuring-pod-distruption-about_nodes-pods-configuring[Using pod disruption budgets to specify the number of pods that must be up]
|
||||
|
||||
@@ -25,12 +25,6 @@ include::modules/olm-dependency-resolution-preferences.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/olm-dependency-resolution-crd-upgrades.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-dependency-resolution-adding-new-crd-version_osdk-generating-csvs[Adding a new CRD version]
|
||||
* xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-dependency-resolution-removing-crd-version_osdk-generating-csvs[Deprecating or removing a CRD version]
|
||||
|
||||
include::modules/olm-dependencies-best-practices.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
@@ -39,4 +33,4 @@ include::modules/olm-dependencies-best-practices.adoc[leveloffset=+1]
|
||||
* Kubernetes documentation: link:https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#readme[Changing the API]
|
||||
|
||||
include::modules/olm-dependencies-caveats.adoc[leveloffset=+1]
|
||||
include::modules/olm-dependency-resolution-examples.adoc[leveloffset=+1]
|
||||
include::modules/olm-dependency-resolution-examples.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,8 +8,6 @@ toc::[]
|
||||
|
||||
Webhooks allow Operator authors to intercept, modify, and accept or reject resources before they are saved to the object store and handled by the Operator controller. Operator Lifecycle Manager (OLM) can manage the lifecycle of these webhooks when they are shipped alongside your Operator.
|
||||
|
||||
See xref:../../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-defining-csv-webhook_osdk-generating-csvs[Defining cluster service versions (CSVs)] for details on how an Operator developer can define webhooks for their Operator, as well as considerations when running on OLM.
|
||||
|
||||
[id="olm-webhooks-additional-resources"]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
Reference in New Issue
Block a user