diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
deleted file mode 100644
index 8c8b1aa238..0000000000
--- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md
+++ /dev/null
@@ -1,237 +0,0 @@
----
-title: Service Catalog
-reviewers:
-- chenopis
-content_type: concept
-weight: 40
----
-
-
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
-
-A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
-Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple Queue Service, and Google Cloud Pub/Sub, but they can be any software offering that can be used by an application.
-
-Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
-
-
-
-
-
-## Example use case
-
-An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster.
-However, they do not want to deal with the overhead of setting such a service up and administering it themselves.
-Fortunately, there is a cloud provider that offers message queuing as a managed service through its service broker.
-
-A cluster operator can setup Service Catalog and use it to communicate with the cloud provider's service broker to provision an instance of the message queuing service and make it available to the application within the Kubernetes cluster.
-The application developer therefore does not need to be concerned with the implementation details or management of the message queue.
-The application can access the message queue as a service.
-
-## Architecture
-
-Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service.
-
-It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture.
-
-
-
-
-
-
-### API Resources
-
-Service Catalog installs the `servicecatalog.k8s.io` API and provides the following Kubernetes resources:
-
-* `ClusterServiceBroker`: An in-cluster representation of a service broker, encapsulating its server connection details.
-These are created and managed by cluster operators who wish to use that broker server to make new types of managed services available within their cluster.
-* `ClusterServiceClass`: A managed service offered by a particular service broker.
-When a new `ClusterServiceBroker` resource is added to the cluster, the Service Catalog controller connects to the service broker to obtain a list of available managed services. It then creates a new `ClusterServiceClass` resource corresponding to each managed service.
-* `ClusterServicePlan`: A specific offering of a managed service. For example, a managed service may have different plans available, such as a free tier or paid tier, or it may have different configuration options, such as using SSD storage or having more resources. Similar to `ClusterServiceClass`, when a new `ClusterServiceBroker` is added to the cluster, Service Catalog creates a new `ClusterServicePlan` resource corresponding to each Service Plan available for each managed service.
-* `ServiceInstance`: A provisioned instance of a `ClusterServiceClass`.
-These are created by cluster operators to make a specific instance of a managed service available for use by one or more in-cluster applications.
-When a new `ServiceInstance` resource is created, the Service Catalog controller connects to the appropriate service broker and instruct it to provision the service instance.
-* `ServiceBinding`: Access credentials to a `ServiceInstance`.
-These are created by cluster operators who want their applications to make use of a `ServiceInstance`.
-Upon creation, the Service Catalog controller creates a Kubernetes `Secret` containing connection details and credentials for the Service Instance, which can be mounted into Pods.
-
-### Authentication
-
-Service Catalog supports these methods of authentication:
-
-* Basic (username/password)
-* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
-
-## Usage
-
-A cluster operator can use Service Catalog API Resources to provision managed services and make them available within a Kubernetes cluster. The steps involved are:
-
-1. Listing the managed services and Service Plans available from a service broker.
-1. Provisioning a new instance of the managed service.
-1. Binding to the managed service, which returns the connection credentials.
-1. Mapping the connection credentials into the application.
-
-### Listing managed services and Service Plans
-
-First, a cluster operator must create a `ClusterServiceBroker` resource within the `servicecatalog.k8s.io` group. This resource contains the URL and connection details necessary to access a service broker endpoint.
-
-This is an example of a `ClusterServiceBroker` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ClusterServiceBroker
-metadata:
- name: cloud-broker
-spec:
- # Points to the endpoint of a service broker. (This example is not a working URL.)
- url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
- #####
- # Additional values can be added here, which may be used to communicate
- # with the service broker, such as bearer token info or a caBundle for TLS.
- #####
-```
-
-The following is a sequence diagram illustrating the steps involved in listing managed services and Plans available from a service broker:
-
-
-
-1. Once the `ClusterServiceBroker` resource is added to Service Catalog, it triggers a call to the external service broker for a list of available services.
-1. The service broker returns a list of available managed services and a list of Service Plans, which are cached locally as `ClusterServiceClass` and `ClusterServicePlan` resources respectively.
-1. A cluster operator can then get the list of available managed services using the following command:
-
- kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
-
- It should output a list of service names with a format similar to:
-
- SERVICE NAME EXTERNAL NAME
- 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
- ... ...
-
- They can also view the Service Plans available using the following command:
-
- kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
-
- It should output a list of plan names with a format similar to:
-
- PLAN NAME EXTERNAL NAME
- 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
- ... ...
-
-
-### Provisioning a new instance
-
-A cluster operator can initiate the provisioning of a new instance by creating a `ServiceInstance` resource.
-
-This is an example of a `ServiceInstance` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ServiceInstance
-metadata:
- name: cloud-queue-instance
- namespace: cloud-apps
-spec:
- # References one of the previously returned services
- clusterServiceClassExternalName: cloud-provider-service
- clusterServicePlanExternalName: service-plan-name
- #####
- # Additional parameters can be added here,
- # which may be used by the service broker.
- #####
-```
-
-The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service:
-
-
-
-1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service.
-1. The service broker creates a new instance of the managed service and returns an HTTP response.
-1. A cluster operator can then check the status of the instance to see if it is ready.
-
-### Binding to a managed service
-
-After a new instance has been provisioned, a cluster operator must bind to the managed service to get the connection credentials and service account details necessary for the application to use the service. This is done by creating a `ServiceBinding` resource.
-
-The following is an example of a `ServiceBinding` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ServiceBinding
-metadata:
- name: cloud-queue-binding
- namespace: cloud-apps
-spec:
- instanceRef:
- name: cloud-queue-instance
- #####
- # Additional information can be added here, such as a secretName or
- # service account parameters, which may be used by the service broker.
- #####
-```
-
-The following sequence diagram illustrates the steps involved in binding to a managed service instance:
-
-
-
-1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance.
-1. The service broker enables the application permissions/roles for the appropriate service account.
-1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services.
-
-### Mapping the connection credentials
-
-After binding, the final step involves mapping the connection credentials and service-specific information into the application.
-These pieces of information are stored in secrets that the application in the cluster can access and use to connect directly with the managed service.
-
-
-
-
-
-#### Pod configuration File
-
-One method to perform this mapping is to use a declarative Pod configuration.
-
-The following example describes how to map service account credentials into the application. A key called `sa-key` is stored in a volume named `provider-cloud-key`, and the application mounts this volume at `/var/secrets/provider/key.json`. The environment variable `PROVIDER_APPLICATION_CREDENTIALS` is mapped from the value of the mounted file.
-
-```yaml
-...
- spec:
- volumes:
- - name: provider-cloud-key
- secret:
- secretName: sa-key
- containers:
-...
- volumeMounts:
- - name: provider-cloud-key
- mountPath: /var/secrets/provider
- env:
- - name: PROVIDER_APPLICATION_CREDENTIALS
- value: "/var/secrets/provider/key.json"
-```
-
-The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`.
-
-
-```yaml
-...
- env:
- - name: "TOPIC"
- valueFrom:
- secretKeyRef:
- name: provider-queue-credentials
- key: topic
-```
-
-
-
-
-## {{% heading "whatsnext" %}}
-
-* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
-* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-
-
-
-
-
diff --git a/content/en/docs/reference/glossary/managed-service.md b/content/en/docs/reference/glossary/managed-service.md
index 186588252c..4752867bb7 100644
--- a/content/en/docs/reference/glossary/managed-service.md
+++ b/content/en/docs/reference/glossary/managed-service.md
@@ -16,7 +16,4 @@ tags:
Some examples of Managed Services are AWS EC2, Azure SQL Database, and
GCP Pub/Sub, but they can be any software offering that can be used by an application.
-[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
-list, provision, and bind with Managed Services offered by
-{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
diff --git a/content/en/docs/reference/glossary/service-broker.md b/content/en/docs/reference/glossary/service-broker.md
deleted file mode 100644
index d35ea3d688..0000000000
--- a/content/en/docs/reference/glossary/service-broker.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Service Broker
-id: service-broker
-date: 2018-04-12
-full_link:
-short_description: >
- An endpoint for a set of Managed Services offered and maintained by a third-party.
-
-aka:
-tags:
-- extension
----
- An endpoint for a set of {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} offered and maintained by a third-party.
-
-
-
-{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the
-[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)
-and provide a standard interface for applications to use their Managed Services.
-[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to
-list, provision, and bind with Managed Services offered by Service Brokers.
-
diff --git a/content/en/docs/reference/glossary/service-catalog.md b/content/en/docs/reference/glossary/service-catalog.md
index 3404543d18..471311426c 100644
--- a/content/en/docs/reference/glossary/service-catalog.md
+++ b/content/en/docs/reference/glossary/service-catalog.md
@@ -4,15 +4,15 @@ id: service-catalog
date: 2018-04-12
full_link:
short_description: >
- An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
+ A former extension API that enabled applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
aka:
tags:
- extension
---
- An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
+ A former extension API that enabled applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
-It provides a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} from {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} without needing detailed knowledge about how those services are created or managed.
+It provided a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} without needing detailed knowledge about how those services would be created or managed.
diff --git a/content/en/docs/tasks/service-catalog/_index.md b/content/en/docs/tasks/service-catalog/_index.md
deleted file mode 100644
index 77e5fa25e4..0000000000
--- a/content/en/docs/tasks/service-catalog/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: "Service Catalog"
-description: Install the Service Catalog extension API.
-weight: 150
----
-
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
deleted file mode 100644
index b01f380a1a..0000000000
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Install Service Catalog using Helm
-reviewers:
-- chenopis
-content_type: task
----
-
-
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
-
-Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster.
-Up to date information on this process can be found at the
-[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
-
-## {{% heading "prerequisites" %}}
-
-* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
-* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
-* You must have a Kubernetes cluster with cluster DNS enabled.
- * If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
- * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
-* [Install and setup kubectl](/docs/tasks/tools/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
-* Install [Helm](https://helm.sh/) v2.7.0 or newer.
- * Follow the [Helm install instructions](https://helm.sh/docs/intro/install/).
- * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
-
-
-
-
-
-## Add the service-catalog Helm repository
-
-Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
-
-```shell
-helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
-```
-
-Check to make sure that it installed successfully by executing the following command:
-
-```shell
-helm search repo service-catalog
-```
-
-If the installation was successful, the command should output the following:
-
-```
-NAME CHART VERSION APP VERSION DESCRIPTION
-svc-cat/catalog 0.2.1 service-catalog API server and controller-manager helm chart
-svc-cat/catalog-v0.2 0.2.2 service-catalog API server and controller-manager helm chart
-```
-
-## Enable RBAC
-
-Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
-
-When using Minikube v0.25 or older, you must run Minikube with RBAC explicitly enabled:
-
-```shell
-minikube start --extra-config=apiserver.Authorization.Mode=RBAC
-```
-
-When using Minikube v0.26+, run:
-
-```shell
-minikube start
-```
-
-With Minikube v0.26+, do not specify `--extra-config`. The flag has since been changed to --extra-config=apiserver.authorization-mode and Minikube now uses RBAC by default. Specifying the older flag may cause the start command to hang.
-
-If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values:
-
-```
-AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
-```
-
-By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account.
-
-{{< note >}}
-If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
-{{< /note >}}
-
-Configure Tiller to have `cluster-admin` access:
-
-```shell
-kubectl create clusterrolebinding tiller-cluster-admin \
- --clusterrole=cluster-admin \
- --serviceaccount=kube-system:default
-```
-
-
-## Install Service Catalog in your Kubernetes cluster
-
-Install Service Catalog from the root of the Helm repository using the following command:
-
-{{< tabs name="helm-versions" >}}
-{{% tab name="Helm version 3" %}}
-```shell
-helm install catalog svc-cat/catalog --namespace catalog
-```
-{{% /tab %}}
-{{% tab name="Helm version 2" %}}
-```shell
-helm install svc-cat/catalog --name catalog --namespace catalog
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-
-
-## {{% heading "whatsnext" %}}
-
-* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-
-
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
deleted file mode 100644
index a724d5b17b..0000000000
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Install Service Catalog using SC
-reviewers:
-- chenopis
-content_type: task
----
-
-
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
-
-You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
-tool to easily install or uninstall Service Catalog on your Kubernetes cluster, linking it to
-Google Cloud projects.
-
-Service Catalog can work with any kind of managed service, not only Google Cloud.
-
-## {{% heading "prerequisites" %}}
-
-* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
-* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
-* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
-* Service Catalog requires Kubernetes version 1.7+.
-* [Install and setup kubectl](/docs/tasks/tools/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
-* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:
-
- kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=
-
-
-
-
-
-## Install `sc` in your local environment
-
-The installer runs on your local computer as a CLI tool named `sc`.
-
-Install using `go get`:
-
-```shell
-go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
-```
-
-`sc` should now be installed in your `GOPATH/bin` directory.
-
-## Install Service Catalog in your Kubernetes cluster
-
-First, verify that all dependencies have been installed. Run:
-
-```shell
-sc check
-```
-
-If the check is successful, it should return:
-
-```
-Dependency check passed. You are good to go.
-```
-
-Next, run the install command and specify the `storageclass` that you want to use for the backup:
-
-```shell
-sc install --etcd-backup-storageclass "standard"
-```
-
-## Uninstall Service Catalog
-
-If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
-
-```shell
-sc uninstall
-```
-
-
-
-
-## {{% heading "whatsnext" %}}
-
-* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-
-
diff --git a/static/images/docs/service-catalog-architecture.svg b/static/images/docs/service-catalog-architecture.svg
deleted file mode 100644
index 57c7558d5a..0000000000
--- a/static/images/docs/service-catalog-architecture.svg
+++ /dev/null
@@ -1,138 +0,0 @@
-
-
-
diff --git a/static/images/docs/service-catalog-bind.svg b/static/images/docs/service-catalog-bind.svg
deleted file mode 100644
index 0a57f944aa..0000000000
--- a/static/images/docs/service-catalog-bind.svg
+++ /dev/null
@@ -1,115 +0,0 @@
-
-
-
diff --git a/static/images/docs/service-catalog-list.svg b/static/images/docs/service-catalog-list.svg
deleted file mode 100644
index ba1802d8fe..0000000000
--- a/static/images/docs/service-catalog-list.svg
+++ /dev/null
@@ -1,136 +0,0 @@
-
-
-
diff --git a/static/images/docs/service-catalog-map.svg b/static/images/docs/service-catalog-map.svg
deleted file mode 100644
index 091cd4efef..0000000000
--- a/static/images/docs/service-catalog-map.svg
+++ /dev/null
@@ -1,100 +0,0 @@
-
-
-
diff --git a/static/images/docs/service-catalog-provision.svg b/static/images/docs/service-catalog-provision.svg
deleted file mode 100644
index 748ba3a336..0000000000
--- a/static/images/docs/service-catalog-provision.svg
+++ /dev/null
@@ -1,125 +0,0 @@
-
-
-