diff --git a/content/en/_redirects b/content/en/_redirects index 35223bc4af..20a0512718 100644 --- a/content/en/_redirects +++ b/content/en/_redirects @@ -202,4 +202,5 @@ docs/started/requirements/ /docs/started/getting-started/ /docs/components/istio/* /docs/external-add-ons/istio/:splat /docs/components/feature-store/* /docs/external-add-ons/feature-store/:splat /docs/components/serving/* /docs/external-add-ons/serving/:splat -/docs/distributions/gke/* https://googlecloudplatform.github.io/kubeflow-gke-docs/docs/:splat \ No newline at end of file +/docs/distributions/gke/* https://googlecloudplatform.github.io/kubeflow-gke-docs/docs/:splat +/docs/distributions/ibm/* https://ibm.github.io/manifests/ \ No newline at end of file diff --git a/content/en/docs/distributions/ibm/OWNERS b/content/en/docs/distributions/ibm/OWNERS index 41cc4556df..787c80886c 100644 --- a/content/en/docs/distributions/ibm/OWNERS +++ b/content/en/docs/distributions/ibm/OWNERS @@ -1,6 +1,3 @@ approvers: - Tomcli - - yhwang -reviewers: - - Tomcli - - yhwang + - yhwang \ No newline at end of file diff --git a/content/en/docs/distributions/ibm/_index.md b/content/en/docs/distributions/ibm/_index.md index 1e4a0ae2d2..9ad051b888 100644 --- a/content/en/docs/distributions/ibm/_index.md +++ b/content/en/docs/distributions/ibm/_index.md @@ -1,5 +1,9 @@ +++ -title = "Kubeflow on IBM Cloud" +title = "Kubeflow on IKS" description = "Running Kubeflow on IBM Cloud Kubernetes Service (IKS)" weight = 20 +++ + +[Kubeflow on IKS](https://ibm.github.io/manifests/) is an open source distribution of the Kubeflow manifests. + +For more information, see the [Kubeflow on IKS documentation](https://ibm.github.io/manifests/docs/). diff --git a/content/en/docs/distributions/ibm/create-cluster-vpc.md b/content/en/docs/distributions/ibm/create-cluster-vpc.md deleted file mode 100644 index c79b8dbe9e..0000000000 --- a/content/en/docs/distributions/ibm/create-cluster-vpc.md +++ /dev/null @@ -1,289 +0,0 @@ -+++ -title = "Create or access an IBM Cloud Kubernetes cluster on a VPC" -description = "Instructions for creating or connecting to a Kubernetes cluster on IBM Cloud vpc-gen2" -weight = 4 -+++ - -## Create and setup a new cluster - -Follow these steps to create and setup a new IBM Cloud Kubernetes Service(IKS) cluster on `vpc-gen2` provider. - -A `vpc-gen2` cluster does not expose each node to the public internet directly and thus has more secure -and more complex network setup. It is recommended setup for secured production use cases of Kubeflow. - -### Setting environment variables - -Choose the region and the worker node provider for your cluster, and set the environment variables. - -```shell -export KUBERNERTES_VERSION=1.18 -export CLUSTER_ZONE=us-south-3 -export CLUSTER_NAME=kubeflow-vpc -``` - -where: - -- `KUBERNETES_VERSION`: Run `ibmcloud ks versions` to see the supported Kubernetes versions. Refer to - [Supported version matrix](https://www.kubeflow.org/docs/started/k8s/overview/#minimum-system-requirements). -- `CLUSTER_ZONE`: Run `ibmcloud ks locations` to list supported zones. For example, choose `us-south-3` to create your - cluster in the Dallas (US) data center. -- `CLUSTER_NAME` must be lowercase and unique among any other Kubernetes - clusters in the specified `${CLUSTER_ZONE}`. - -**Notice**: Refer to [Creating clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusters) in the IBM -Cloud documentation for additional information on how to set up other providers and zones in your cluster. - -### Choosing a worker node flavor - -The worker nodes flavor name varies from zones and providers. Run -`ibmcloud ks flavors --zone ${CLUSTER_ZONE} --provider vpc-gen2` to list available flavors. - -Below are some examples of flavors supported in the `us-south-3` zone with `vpc-gen2` node provider: - -```shell -ibmcloud ks flavors --zone us-south-3 --provider vpc-gen2 -``` - -Example output: - -``` -For more information about these flavors, see 'https://ibm.biz/flavors' -Name Cores Memory Network Speed OS Server Type Storage Secondary Storage Provider -bx2.16x64 16 64GB 16Gbps UBUNTU_18_64 virtual 100GB 0B vpc-gen2 -bx2.2x8† 2 8GB 4Gbps UBUNTU_18_64 virtual 100GB 0B vpc-gen2 -bx2.32x128 32 128GB 16Gbps UBUNTU_18_64 virtual 100GB 0B vpc-gen2 -bx2.48x192 48 192GB 16Gbps UBUNTU_18_64 virtual 100GB 0B vpc-gen2 -bx2.4x16 4 16GB 8Gbps UBUNTU_18_64 virtual 100GB 0B vpc-gen2 -... -``` - -The recommended configuration for a cluster is at least 8 vCPU cores with 16GB memory. Hence, we recommend -`bx2.4x16` flavor to create a two-worker-node cluster. Keep in mind that you can always scale the cluster -by adding more worker nodes should your application scales up. - -Now set the environment variable with the flavor you choose. - -```shell -export WORKER_NODE_FLAVOR=bx2.4x16 -``` - -## Create an IBM Cloud Kubernetes cluster for `vpc-gen2` infrastructure - -Creating a `vpc-gen2` based cluster needs a VPC, a subnet and a public gateway attached to it. Fortunately, this is a one -time setup. Future `vpc-gen2` clusters can reuse the same VPC/subnet(with attached public-gateway). - -1. Begin with installing a `vpc-infrastructure` plugin: - - ```shell - ibmcloud plugin install vpc-infrastructure - ``` - - Refer to this [link](https://cloud.ibm.com/docs/containers?topic=containers-vpc_ks_tutorial), for more information. - -2. Target `vpc-gen 2` to access gen 2 VPC resources: - - ```shell - ibmcloud is target --gen 2 - ``` - - Verify that the target is correctly set up: - - ```shell - ibmcloud is target - ``` - - Example output: - - ``` - Target Generation: 2 - ``` - -3. Create or use an existing VPC: - - a) Use an existing VPC: - - ```shell - ibmcloud is vpcs - ``` - - - Example output: - ``` - Listing vpcs for generation 2 compute in all resource groups and region ... - ID Name Status Classic access Default network ACL Default security group Resource group - r006-hidden-68cc-4d40-xxxx-4319fa3gxxxx my-vpc1 available false husker-sloping-bee-resize blimp-hasty-unaware-overflow kubeflow - ``` - - If the above list contains the VPC that can be used to deploy your cluster - make a note of its ID. - - b) To create a new VPC, proceed as follows: - - ```shell - ibmcloud is vpc-create my-vpc - ``` - - Example output: - - ``` - Creating vpc my-vpc in resource group kubeflow under account IBM as ... - - ID r006-hidden-68cc-4d40-xxxx-4319fa3fxxxx - Name my-vpc - ... - ``` - - **Save the ID in a variable `VPC_ID` as follows, so that we can use it later.** - - ```shell - export VPC_ID=r006-hidden-68cc-4d40-xxxx-4319fa3fxxxx - ``` - -4. Create or use an existing subnet: - - a) To use an existing subnet: - - ```shell - ibmcloud is subnets - ``` - - Example output: - - ``` - Listing subnets for generation 2 compute in all resource groups and region ... - ID Name Status Subnet CIDR Addresses ACL Public Gateway VPC Zone Resource group - 0737-27299d09-1d95-4a9d-a491-a6949axxxxxx my-subnet available 10.240.128.0/18 16373/16384 husker-sloping-bee-resize my-gateway my-vpc us-south-3 kubeflow - ``` - - If the above list contains the subnet corresponding to your VPC, that can be used to deploy your cluster - make sure - you note it's ID. - - b) To create a new subnet: - - List address prefixes and note the CIDR block corresponding to a Zone; - in the below example, for Zone: `us-south-3` the CIDR block is : `10.240.128.0/18`. - - ```shell - ibmcloud is vpc-address-prefixes $VPC_ID - ``` - - Example output: - - ``` - Listing address prefixes of vpc r006-hidden-68cc-4d40-xxxx-4319fa3fxxxx under account IBM as user new@user-email.com... - ID Name CIDR block Zone Has subnets Is default Created - r006-xxxxxxxx-4002-46d2-8a4f-f69e7ba3xxxx rising-rectified-much-brew 10.240.0.0/18 us-south-1 false true 2021-03-05T14:58:39+05:30 - r006-xxxxxxxx-dca9-4321-bb6c-960c4424xxxx retrial-reversal-pelican-cavalier 10.240.64.0/18 us-south-2 false true 2021-03-05T14:58:39+05:30 - r006-xxxxxxxx-7352-4a46-bfb1-fcbac6cbxxxx subfloor-certainly-herbal-ajar 10.240.128.0/18 us-south-3 false true 2021-03-05T14:58:39+05:30 - ``` - - - Now create a subnet as follows: - - ```shell - ibmcloud is subnet-create my-subnet $VPC_ID $CLUSTER_ZONE --ipv4-cidr-block "10.240.128.0/18" - ``` - - Example output: - - ``` - Creating subnet my-subnet in resource group kubeflow under account IBM as user new@user-email.com... - - ID 0737-27299d09-1d95-4a9d-a491-a6949axxxxxx - Name my-subnet - ``` - - - Make sure you export the subnet IDs follows: - - ```shell - export SUBNET_ID=0737-27299d09-1d95-4a9d-a491-a6949axxxxxx - ``` - -5. Create a `vpc-gen2` based Kubernetes cluster: - - ```shell - ibmcloud ks cluster create vpc-gen2 \ - --name $CLUSTER_NAME \ - --zone $CLUSTER_ZONE \ - --version ${KUBERNETES_VERSION} \ - --flavor ${WORKER_NODE_FLAVOR} \ - --vpc-id ${VPC_ID} \ - --subnet-id ${SUBNET_ID} \ - --workers 2 - ``` - -6. Attach a public gateway - - This step is mandatory for Kubeflow deployment to succeed, because pods need public internet access to download images. - - - First, check if your cluster is already assigned a public gateway: - - ```shell - ibmcloud is pubgws - ``` - - Example output: - - ``` - Listing public gateways for generation 2 compute in all resource groups and region ... - ID Name Status Floating IP VPC Zone Resource group - r006-xxxxxxxx-5731-4ffe-bc51-1d9e5fxxxxxx my-gateway available xxx.xxx.xxx.xxx my-vpc us-south-3 default - - ``` - - In the above run, the gateway is already attached for the vpc: `my-vpc`. In case no gateway is attached, proceed with - the rest of the setup. - - - Next, attach a public gateway by running the following command: - - ```shell - ibmcloud is public-gateway-create my-gateway $VPC_ID $CLUSTER_ZONE - ``` - - Example output: - ``` - ID: r006-xxxxxxxx-5731-4ffe-bc51-1d9e5fxxxxxx - ``` - - Save the above generated gateway ID as follows: - - ```shell - export GATEWAY_ID="r006-xxxxxxxx-5731-4ffe-bc51-1d9e5fxxxxxx" - ``` - - - Finally, attach the public gateway to the subnet: - - ```shell - ibmcloud is subnet-update $SUBNET_ID --public-gateway-id $GATEWAY_ID - ``` - - Example output: - - ``` - Updating subnet 0737-27299d09-1d95-4a9d-a491-a6949axxxxxx under account IBM as user new@user-email.com... - - ID 0737-27299d09-1d95-4a9d-a491-a6949axxxxxx - Name my-subnet - ... - ``` - -### Verifying the cluster - -To use the created cluster, switch the Kubernetes context to point to the cluster: - -```shell -ibmcloud ks cluster config --cluster ${CLUSTER_NAME} -``` - -Make sure all worker nodes are up with the command below: - -```shell -kubectl get nodes -``` - -and verify that all the nodes are in `Ready` state. - -### Delete the cluster - -Delete the cluster including it's storage: - -```shell -ibmcloud ks cluster rm --force-delete-storage -c ${CLUSTER_NAME} -``` diff --git a/content/en/docs/distributions/ibm/create-cluster.md b/content/en/docs/distributions/ibm/create-cluster.md deleted file mode 100644 index 046eb3e785..0000000000 --- a/content/en/docs/distributions/ibm/create-cluster.md +++ /dev/null @@ -1,189 +0,0 @@ -+++ -title = "Create or access an IBM Cloud Kubernetes cluster" -description = "Instructions for creating or connecting to a Kubernetes cluster on IBM Cloud" -weight = 3 -+++ - -This guide describes how to create a Kubernetes cluster with IBM Cloud Kubernetes Service. - -[IBM Cloud Kubernetes Service](https://www.ibm.com/cloud/kubernetes-service) provides powerful tools and services to help deploy highly available containerized apps in Kubernetes clusters and to automate, isolate, secure, manage, and monitor your workloads across zones or regions. - -## Prerequisites - -1. `IBMid` - - To get started, first go to [IBM Cloud](https://ibm.biz/Bdqgck) to create your `IBMid` if you do not have one. - -2. Installing the IBM Cloud CLI - - Follow the instructions in this [Getting started with the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started#overview) guide to install the IBM Cloud CLI. - -3. Installing the IBM Cloud Kubernetes Service plug-in with the command - - ```shell - ibmcloud plugin install container-service - ``` - - Refer to this [link](https://cloud.ibm.com/docs/cli?topic=containers-kubernetes-service-cli) for more info on IBM Cloud Kubernetes Service CLI. - -4. Authenticating with IBM Cloud - - ```shell - ibmcloud login - ``` - - Use your registered email and password for your `IBMid` to log in to IBM Cloud. - -## Connecting to an existing cluster - -If you have an existing cluster, use it to install Kubeflow as far as it meets the minimum system requirement. - -Get the Kubeconfig file: - -```shell -ibmcloud ks cluster config --cluster $CLUSTER_NAME -``` - -From here on, go to [Install Kubeflow on IKS](/docs/ibm/deploy/install-kubeflow-on-iks) for more information. - - -## Create and setup a new cluster - -* Use a `classic` provider if you want to try out Kubeflow. -* Use a `vpc-gen2` provider if you are familiar with Cloud networking and want to deploy Kubeflow on a secure environment. - -A `classic` provider exposes each cluster node to the public internet and therefore has -a relatively simpler networking setup. Services exposed using Kubernetes `NodePort` need to be secured using -authentication mechanism. - -To create a cluster with `vpc-gen2` provider, follow the -[Create a cluster on IKS with a `vpc-gen2` provider](/docs/ibm/create-cluster-vpc) -guide. - -The next section will explain how to create and set up a new IBM Cloud Kubernetes Service (IKS) - -### Setting environment variables - -Choose the region and the worker node provider for your cluster, and set the environment variables. - -```shell -export KUBERNETES_VERSION=1.21 -export CLUSTER_ZONE=dal13 -export WORKER_NODE_PROVIDER=classic -export CLUSTER_NAME=kubeflow -``` - -where: - -- `KUBERNETES_VERSION` specifies the Kubernetes version for the cluster. Run `ibmcloud ks versions` to see the supported - Kubernetes versions. If this environment variable is not set, the cluster will be created with the default version set - by IBM Cloud Kubernetes Service. Refer to - [Minimum system requirements](https://www.kubeflow.org/docs/started/k8s/overview/#minimum-system-requirements) - and choose a Kubernetes version compatible with the Kubeflow release to be deployed. -- `CLUSTER_ZONE` identifies the regions or location where cluster will be created. Run `ibmcloud ks locations` to - list supported IBM Cloud Kubernetes Service locations. For example, choose `dal13` to create your cluster in the - Dallas (US) data center. -- `WORKER_NODE_PROVIDER` specifies the kind of IBM Cloud infrastructure on which the Kubernetes worker nodes will be - created. The `classic` type supports worker nodes with GPUs. There are other worker nodes providers including - `vpc-classic` and `vpc-gen2` where zone names and worker flavors will be different. Run - `ibmcloud ks zones --provider classic` to list zone names for `classic` provider and set the `CLUSTER_ZONE` - accordingly. -- `CLUSTER_NAME` must be lowercase and unique among any other Kubernetes - clusters in the specified `${CLUSTER_ZONE}`. - -**Notice**: Refer to [Creating clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusters) in the IBM -Cloud documentation for additional information on how to set up other providers and zones in your cluster. - -### Choosing a worker node flavor - -The worker node flavor name varies from zones and providers. Run -`ibmcloud ks flavors --zone ${CLUSTER_ZONE} --provider ${WORKER_NODE_PROVIDER}` to list available flavors. - -For example, the following are some worker node flavors supported in the `dal13` zone with a `classic` node provider. - -```shell -ibmcloud ks flavors --zone dal13 --provider classic -``` - -Example output: - -``` -OK -For more information about these flavors, see 'https://ibm.biz/flavors' -Name Cores Memory Network Speed OS Server Type Storage Secondary Storage Provider -b2c.16x64 16 64GB 1000Mbps UBUNTU_16_64 virtual 25GB 100GB classic -b2c.32x128 32 128GB 1000Mbps UBUNTU_16_64 virtual 25GB 100GB classic -b2c.4x16 4 16GB 1000Mbps UBUNTU_16_64 virtual 25GB 100GB classic -b2c.56x242 56 242GB 1000Mbps UBUNTU_16_64 virtual 25GB 100GB classic -b2c.8x32 8 32GB 1000Mbps UBUNTU_16_64 virtual 25GB 100GB classic -b3c.16x64 16 64GB 1000Mbps UBUNTU_18_64 virtual 25GB 100GB classic -b3c.32x128 32 128GB 1000Mbps UBUNTU_18_64 virtual 25GB 100GB classic -b3c.4x16 4 16GB 1000Mbps UBUNTU_18_64 virtual 25GB 100GB classic -b3c.56x242 56 242GB 1000Mbps UBUNTU_18_64 virtual 25GB 100GB classic -b3c.8x32 8 32GB 1000Mbps UBUNTU_18_64 virtual 25GB 100GB classic -... -``` - -Choose a flavor that will work for your applications. For the purpose of the Kubeflow deployment, the recommended -configuration for a cluster is at least 8 vCPU cores with 16GB memory. Hence you can either choose the `b3c.8x32` flavor -to create a one-worker-node cluster or choose the `b3c.4x16` flavor to create a two-worker-node cluster. Keep in mind -that you can always scale the cluster by adding more worker nodes should your application scales up. - -Now, set the environment variable with the worker node flavor of your choice: - -```shell -export WORKER_NODE_FLAVOR=b3c.4x16 -``` - -### Creating an IBM Cloud Kubernetes cluster - -Run with the following command to create a cluster: - -Replace the `workers` parameter above with the desired number of worker nodes. - -If you're starting in a fresh account with no public and private VLANs, they are created automatically for you -when creating a Kubernetes cluster with worker nodes provider `classic` for the first time. If you already have VLANs -configured in your account, retrieve them via `ibmcloud ks vlans --zone ${CLUSTER_ZONE}` and include the public and -private VLAN ids (set in the `PUBLIC_VLAN_ID` and `PRIVATE_VLAN_ID` environment variables) in the command. - -```shell -ibmcloud ks cluster create ${WORKER_NODE_PROVIDER} \ - --name=$CLUSTER_NAME \ - --zone=$CLUSTER_ZONE \ - --version=${KUBERNETES_VERSION} \ - --flavor ${WORKER_NODE_FLAVOR} \ - --workers=2 \ - --private-vlan ${PRIVATE_VLAN_ID} \ - --public-vlan ${PUBLIC_VLAN_ID} -``` - -Wait until the cluster is deployed and configured. It can take a while for the cluster to be ready. Run with following -command to periodically check the state of your cluster. Your cluster is ready when the state is `normal`. - -```shell -ibmcloud ks clusters --provider ${WORKER_NODE_PROVIDER} |grep ${CLUSTER_NAME} |awk '{print "Name:"$1"\tState:"$3}' -``` - -### Verifying the cluster - -To use the created cluster, switch the Kubernetes context to point to the cluster with the command - -```shell -ibmcloud ks cluster config --cluster ${CLUSTER_NAME} -``` - -Make sure all worker nodes are up with the command below - -```shell -kubectl get nodes -``` - -and make sure all the nodes are in `Ready` state. - -### Delete the cluster - -Delete the cluster including it's storage: - -```shell -ibmcloud ks cluster rm --force-delete-storage -c ${CLUSTER_NAME} -``` diff --git a/content/en/docs/distributions/ibm/deploy/OWNERS b/content/en/docs/distributions/ibm/deploy/OWNERS deleted file mode 100644 index 41cc4556df..0000000000 --- a/content/en/docs/distributions/ibm/deploy/OWNERS +++ /dev/null @@ -1,6 +0,0 @@ -approvers: - - Tomcli - - yhwang -reviewers: - - Tomcli - - yhwang diff --git a/content/en/docs/distributions/ibm/deploy/_index.md b/content/en/docs/distributions/ibm/deploy/_index.md deleted file mode 100644 index 57473894a8..0000000000 --- a/content/en/docs/distributions/ibm/deploy/_index.md +++ /dev/null @@ -1,5 +0,0 @@ -+++ -title = "Kubeflow Deployment on IBM Cloud" -description = "Instructions for Kubeflow deployment on IBM Cloud" -weight = 4 -+++ diff --git a/content/en/docs/distributions/ibm/deploy/authentication.md b/content/en/docs/distributions/ibm/deploy/authentication.md deleted file mode 100644 index 2700efa5dc..0000000000 --- a/content/en/docs/distributions/ibm/deploy/authentication.md +++ /dev/null @@ -1,274 +0,0 @@ -+++ -title = "Securing the Kubeflow authentication with HTTPS" -description = "How to secure the Kubeflow authentication with HTTPS using the network load balancer" -weight = 10 -+++ - -This guide describes how to secure the Kubeflow authentication with HTTPS. -You can enable HTTPS for Kubeflow dashboard (and other web UIs) using the -network load balancer (NLB) feature of the IBM Cloud Kubernetes service—choose -the `classic` worker nodes provider in the -[Setting environment variables](../../create-cluster#setting-environment-variables) -section of the Create an IBM Cloud cluster guide. - -**Note**: For details on NLB, go to the official -[Classic: About network load balancers](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-about) -guide. - -## Prerequisites - -* Install and configure the -[IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started). -* Install -[multi-user, auth-enabled Kubeflow](../install-kubeflow-on-iks/#multi-user-auth-enabled). - -## Setting up an NLB - -To set up an NLB for your Kubernetes cluster, follow the official -[Classic: Setting up basic load balancing with an NLB 1.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer) -guide. Notice that the setup process for a multi-zone cluster differs from that -of a single-zone cluster. For details, go to -[Setting up an NLB 1.0 in a multi-zone cluster](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer#multi_zone_config). - -1. To use the existing Istio ingress gateway (instead of creating a new -service), you need to update the service type of `istio-ingressgateway` to -`LoadBalancer` from `NodePort`. Run the following command: - - ```shell - kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"type":"LoadBalancer"}}' - ``` - -2. Verify that the NLB was created successfully. It might take a few minutes for -the service to be created and an IP address to be made available. Run the -command below and check if you can see the `LoadBalancer Ingress` IP address: - - ```shell - kubectl describe service istio-ingressgateway -n istio-system | grep "LoadBalancer Ingress" - ``` - -3. Store the external IP of the `istio-ingressgateway` service in an environment -variable: - - ```shell - export INGRESS_GATEWAY_IP=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') - ``` - -## Exposing the Kubeflow dashboard with DNS and TLS termination - -The following instructions use the Kubeflow dashboard as an example. However, -they apply to other web UI applications, since they all go through the Istio -ingress gateway. - -1. Store the Kubernetes cluster name in an environment variable by running the -following command: - - ```shell - export CLUSTER_NAME= - ``` - -2. Create a DNS domain and certificates for the IP of the service -`istio-ingressgateway` in namespace `istio-system`: - - ```shell - ibmcloud ks nlb-dns create classic --cluster $CLUSTER_NAME --ip $INGRESS_GATEWAY_IP --secret-namespace istio-system - ``` - -3. List the registered domain names: - - ```shell - ibmcloud ks nlb-dns ls --cluster $CLUSTER_NAME - ``` - -4. Wait until the status of the certificate—the fourth field—of the new domain -name becomes `created`. Then, save the value of the column `SSL Cert Secret -Name` in environment variables by running these commands (replace -`{SECRET_NAME}` with the secret's name as shown in the `SSL Cert Secret Name` -column): - - ```shell - export INGRESS_GATEWAY_SECRET={SECRET_NAME} - ``` - - **Note**: If there is more than one entry in the output, choose the one - that matches the IP address from `LoadBalancer Ingress` (step 2) of service - `istio-ingressgateway`. - -5. Create a secret named `istio-ingressgateway-certs` for the -`istio-ingressgateway` pods in namespace `istio-system`: - - ```shell - kubectl get secret $INGRESS_GATEWAY_SECRET -n istio-system -o yaml > istio-ingressgateway-certs.yaml - ``` - -6. Update the `istio-ingressgateway-certs.yaml` file by changing the value of -`metadata.name` to `istio-ingressgateway-certs` and the value of -`metadata.namespace` to `istio-system`. Then, run the following commands: - - ```shell - kubectl apply -f istio-ingressgateway-certs.yaml -n istio-system - kubectl rollout restart deploy istio-ingressgateway -n istio-system - rm istio-ingressgateway-certs.yaml - ``` - -7. Update the gateway `kubeflow-gateway` to expose port `443`. Create a resource -file `kubeflow-gateway.yaml` as follows by replacing `` with the value -of the column `Hostname` in step 4: - - ```YAML - apiVersion: networking.istio.io/v1alpha3 - kind: Gateway - metadata: - name: kubeflow-gateway - namespace: kubeflow - spec: - selector: - istio: ingressgateway - servers: - - hosts: - - '' - port: - name: https - number: 443 - protocol: HTTPS - tls: - mode: SIMPLE - privateKey: /etc/istio/ingressgateway-certs/tls.key - serverCertificate: /etc/istio/ingressgateway-certs/tls.crt - ``` - -8. Verify that the traffic is routed via HTTPS by using the value of -above-mentioned `Hostname` in your browser. It should redirect traffic from an -HTTP address to HTTPS address automatically. - -**Note**: The certificates for the NLB DNS host secret expire every **90** days. -The secret in the `default` namespace is automatically renewed by IBM Cloud -Kubernetes Service 37 days before it expires. After this secret is updated, you -must manually copy it to the `istio-ingressgateway-certs` secret by repeating -commands in step 5 and 6. - -## Optional - KServe configuration - -With this HTTPS setup, you need to make additional changes to get KServe to work. - -1. First, update the Knative domain that is used for the KServe routes to the -hostname that you used when updating `kubeflow-gateway`. - - ```shell - kubectl edit configmap config-domain -n knative-serving - ``` - - This will open your default text editor, and you will see something like: - - ```YAML - apiVersion: v1 - data: - _example: | - ################################ - # # - # EXAMPLE CONFIGURATION # - # # - ################################ - # ... - example.com: | - kind: ConfigMap - ... - ``` - - Add a line above the `_example` key with your hostname as the key and an empty string value. - Be sure to update ``: - - ```YAML - apiVersion: v1 - data: - : "" - _example: | - ... - kind: ConfigMap - ... - ``` - - Then, save and exit. The routes for your InferenceServices will start using this new domain. - -2. Since the certificates provided by IBM Cloud only allow for a single level of domain name added -to the base domain, the domain template for Knative needs to be adjusted so that the certificates -will be valid for the InferenceService routes. - - ```shell - kubectl edit configmap config-network -n knative-serving - ``` - - This will open your default text editor, and you will again see something like: - - ```YAML - apiVersion: v1 - data: - _example: | - ################################ - # # - # EXAMPLE CONFIGURATION # - # # - ################################ - # ... - kind: ConfigMap - ... - ``` - - Add a line above the `_example` key with the `domainTemplate` key like the following: - - ```YAML - apiVersion: v1 - data: - domainTemplate: "{{.Name}}-{{.Namespace}}.{{.Domain}}" - _example: | - ... - kind: ConfigMap - ... - ``` - - Save and exit. The default template uses a two-level subdomain (i.e. `{{.Name}}.{{.Namespace}}.{{.Domain}}`), - so this just adjusts it to use one. - - -3. Adjust `kubeflow-gateway` one more time, adding a wildcard host in the HTTPS `hosts` section. - - ```shell - kubectl edit gateway kubeflow-gateway -n kubeflow - ``` - - This will open your default text editor, but you can also optionally edit `kubeflow-gateway.yaml` file - you created previously. Here, just add another entry to the HTTPS `hosts` list containing your hostname prepended - with a `*.` so that the Knative subdomains are properly routed. - - ```YAML - apiVersion: networking.istio.io/v1alpha3 - kind: Gateway - metadata: - name: kubeflow-gateway - namespace: kubeflow - spec: - selector: - istio: ingressgateway - servers: - - hosts: - - '' - - '*.' - port: - name: https - number: 443 - protocol: HTTPS - tls: - mode: SIMPLE - privateKey: /etc/istio/ingressgateway-certs/tls.key - serverCertificate: /etc/istio/ingressgateway-certs/tls.crt - ``` - - Save and exit. - -After these adjustments, InferenceServices should now be reachable via HTTPS. To test out an external -prediction, you can use the `authservice_session` cookie for the Kubeflow dashboard site from the browser. Once -the content of the cookie is retrieved from the browser, it can be added as a header in your request -(e.g. `"Cookie: authservice_session=MTYwNz..."`). For example: - -```shell -curl -v https://sklearn-iris-kserve-test.kf-dev-442dbba0442be6c8c50f31ed96b00532-0001.sjc03.containers.appdomain.cloud/v1/models/sklearn-iris:predict -d '{"instances": [[6.8, 2.8, 4.8, 1.4],[6.0, 3.4, 4.5, 1.6]]}' -H "Cookie: authservice_session=MTYwODMyODk5M3xOd3dBTkVzeU5VSlJRazlQVnpWT1dGUldWa0ZXVDBRMVFsY3pVVFZHVVVGV01rWkRORmd6VmxCVVNsQkVSa2xaUlZVMFRUVldVMEU9fJBHfRCAvs6nSh_J04VlBEq_yqhkUvc5Z1Mqahe9klOd" -``` diff --git a/content/en/docs/distributions/ibm/deploy/deployment-process.md b/content/en/docs/distributions/ibm/deploy/deployment-process.md deleted file mode 100644 index b8702b06e0..0000000000 --- a/content/en/docs/distributions/ibm/deploy/deployment-process.md +++ /dev/null @@ -1,38 +0,0 @@ -+++ -title = "Kubeflow Deployment Process" -description = "How kubeflow installation works" -weight = 5 -+++ - -## Understanding the Kubeflow deployment process - -The deployment process is controlled by the following commands: - -* **kustomize build** - Use kustomize to generate configuration files defining - the various resources for your deployment. . -* **kubectl apply** - Apply the resources created by `kustomize build` to the - kubenetes cluster - -### Repository layout - -IBM manifests repository contains the following files and directories: - -* **iks-single** directory: A kustomize file for single-user deployment -* **iks-multi** directory: A kustomize file for multi-user deployment - -* **others** Other files are used to compose Kubeflow resources - -## Kubeflow installation - -Starting from Kubeflow 1.3, the official installation documentation uses a combination of `kustomize` and `kubectl` to install Kubeflow. - -### Install kubectl and kustomize - -* [Install kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) -* [Download kustomize 5.0.0](https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv5.0.0) - - ## Next Steps - - 1. Check [Kubeflow Compatibility](/docs/distributions/ibm/deploy/iks-compatibility) - 2. Go here for installing [Kubeflow on IKS](/docs/distributions/ibm/deploy/install-kubeflow-on-iks) - 3. Go here for installing [Kubeflow on IBM OpenShift](/docs/distributions/ibm/deploy/install-kubeflow-on-ibm-openshift) diff --git a/content/en/docs/distributions/ibm/deploy/iks-compatibility.md b/content/en/docs/distributions/ibm/deploy/iks-compatibility.md deleted file mode 100644 index 3140aae514..0000000000 --- a/content/en/docs/distributions/ibm/deploy/iks-compatibility.md +++ /dev/null @@ -1,39 +0,0 @@ -+++ -title = "IBM Cloud Kubernetes and Kubeflow Compatibility" -description = "Compatibility matrix for Kubeflow on IBM Cloud by Kubernetes version" -weight = 6 -+++ - -## Compatibility - -The following table relates compatibility between Kubernetes versions 1.22+ of IBM Cloud Kubernetes service and Kubeflow version 1.7. - -
- - - - - - - - - - - - - - - - - -
IBM Cloud Kubernetes VersionsKubeflow 1.7.0
1.24Compatible
1.25Compatible
-
- -- **Incompatible**: the combination is not known to work together -- **Compatible**: all Kubeflow features have been tested and verified for the IKS Kubernetes version -- **No known issues**: the combination has not been fully tested but there are no reported issues - - -## Next Steps - -1. 2. Go here for installing [Kubeflow on IKS](/docs/distributions/ibm/deploy/install-kubeflow-on-iks) \ No newline at end of file diff --git a/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-IBM-openshift.md b/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-IBM-openshift.md deleted file mode 100644 index 4beda402be..0000000000 --- a/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-IBM-openshift.md +++ /dev/null @@ -1,99 +0,0 @@ -+++ -title = "Install Kubeflow on OpenShift" -description = "Instructions for deploying Kubeflow on IBM Cloud OpenShift" -weight = 7 -+++ - -**This guide has not yet been updated for Kubeflow 1.3** - -This guide describes how to use the kfctl binary to deploy Kubeflow on IBM Cloud Kubernetes Service (IKS). - -## Prerequisites - -* Authenticate with IBM Cloud - - Log into IBM Cloud at [IBM Cloud](https://cloud.ibm.com) - -* Install OpenShift CLI - - OpenShift CLI is the way to manage and access OpenShift cluster. You can [Install OpenShift CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-cli) from this instructions. - -* Create and access a OpenShift cluster on IKS - - To deploy Kubeflow on IBM Cloud, you need a cluster running OpenShift on IKS. If you don't have a cluster running, follow the [Create an IBM Cloud OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) guide. - - To access the cluster follow these directions [Access OpenShift Cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster). We can easily get access from the openshift console on IBM Cloud[Connecting to the cluster from the console](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster#access_oc_console). - - -## Installation - -If you're experiencing issues during the installation because of conflicts on your Kubeflow deployment, you can [uninstall Kubeflow](/docs/ibm/deploy/uninstall-kubeflow) and install it again. - -### Single user - -Run the following commands to set up and deploy Kubeflow for a single user without any authentication. - -**Note**: By default, Kubeflow deployment on IBM Cloud uses the [Kubeflow pipeline with the Tekton backend](https://github.com/kubeflow/kfp-tekton#kubeflow-pipelines-with-tekton). -If you want to use the Kubeflow pipeline with the Argo backend, you can change `CONFIG_URI` to this kfdef instead - -``` -https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_openshift.v1.2.0.yaml -``` - -```shell -# Set KF_NAME to the name of your Kubeflow deployment. This also becomes the -# name of the directory containing your configuration. -# For example, your deployment name can be 'my-kubeflow' or 'kf-test'. -export KF_NAME= - -# Set the path to the base directory where you want to store one or more -# Kubeflow deployments. For example, /opt/. -# Then set the Kubeflow application directory for this deployment. -export BASE_DIR= -export KF_DIR=${BASE_DIR}/${KF_NAME} - -# Set the configuration file to use, such as: -export CONFIG_FILE=kfctl_ibm.yaml -export CONFIG_URI="https://raw.githubusercontent.com/kubeflow/manifests/master/distributions/kfdef/kfctl_openshift.master.kfptekton.yaml" - -# Generate Kubeflow: -mkdir -p ${KF_DIR} -cd ${KF_DIR} - -wget ${CONFIG_URI} -O ${CONFIG_FILE} - -# On MacOS -sed -i '' -e 's#https://github.com/kubeflow/manifests/archive/master.tar.gz#https://github.com/kubeflow/manifests/archive/552a4ba84567ed8c0f9abca12f15b8eed000426c.tar.gz#g' ${CONFIG_FILE} - -# On Linux -sed -i -e 's#https://github.com/kubeflow/manifests/archive/master.tar.gz#https://github.com/kubeflow/manifests/archive/552a4ba84567ed8c0f9abca12f15b8eed000426c.tar.gz#g' ${CONFIG_FILE} - -# Deploy Kubeflow. You can customize the CONFIG_FILE if needed. -kfctl apply -V -f ${CONFIG_FILE} -``` - -* **${KF_NAME}** - The name of your Kubeflow deployment. - If you want a custom deployment name, specify that name here. - For example, `my-kubeflow` or `kf-test`. - The value of KF_NAME must consist of lower case alphanumeric characters or - '-', and must start and end with an alphanumeric character. - The value of this variable cannot be greater than 25 characters. It must - contain just a name, not a directory path. - This value also becomes the name of the directory where your Kubeflow - configurations are stored, that is, the Kubeflow application directory. - -* **${KF_DIR}** - The full path to your Kubeflow application directory. - -The Kubeflow deployment is exposed with a Route. To find the Route you can use - -``` -oc get route -n istio-system istio-ingressgateway -o=jsonpath='{.spec.host}' -``` - -## Next steps - -To secure the Kubeflow dashboard with HTTPS, follow the steps in [Exposing the Kubeflow dashboard with DNS and TLS termination](/docs/ibm/deploy/authentication/#setting-up-an-nlb). - -## Additional information - -You can find general information about Kubeflow configuration in the guide to [configuring Kubeflow with kfctl and kustomize](/docs/other-guides/kustomize/). diff --git a/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-iks.md b/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-iks.md deleted file mode 100644 index 07e9a25681..0000000000 --- a/content/en/docs/distributions/ibm/deploy/install-kubeflow-on-iks.md +++ /dev/null @@ -1,327 +0,0 @@ -+++ -title = "Install Kubeflow on IKS" -description = "Instructions for deploying Kubeflow on IBM Cloud Kubernetes Service" -weight = 6 -+++ - -This guide describes how to use the kustomize + kubectl to deploy Kubeflow on IBM Cloud Kubernetes Service (IKS). - -## Prerequisites - -* Authenticate with IBM Cloud - - Log into IBM Cloud using the [IBM Cloud Command Line Interface (CLI)](https://www.ibm.com/cloud/cli) as follows: - - ```shell - ibmcloud login - ``` - - Or, if you have federated credentials, run the following command: - - ```shell - ibmcloud login --sso - ``` - -* Create and access a Kubernetes cluster on IKS - - To deploy Kubeflow on IBM Cloud, you need a cluster running on IKS. If you don't have a cluster running, follow the [Create an IBM Cloud cluster](/docs/ibm/create-cluster) guide. - - Run the following command to switch the Kubernetes context and access the cluster: - - ```shell - ibmcloud ks cluster config --cluster - ``` - - Replace `` with your cluster name. - -* kustomize (version 5.0.0) ([download link](https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv5.0.0)) - -* [Python 3](https://www.python.org/downloads/) with [passlib](https://pypi.org/project/passlib/) - and [bcrypt](https://pypi.org/project/bcrypt/) packages installed - -### Storage setup for a **Classic** IBM Cloud Kubernetes cluster - -**Note**: This section is only required when the worker nodes provider `WORKER_NODE_PROVIDER` is set to `classic`. For other infrastructures, IBM Cloud Storage with Group ID support is already set up as the cluster's default storage class. - -When you use the `classic` worker node provider of an IBM Cloud Kubernetes cluster, it uses the regular [IBM Cloud File Storage](https://www.ibm.com/cloud/file-storage) based on NFS as the default storage class. File Storage is designed to run RWX (read-write multiple nodes) workloads with proper security built around it. Therefore, File Storage [does not allow `fsGroup` securityContext](https://cloud.ibm.com/docs/containers?topic=containers-security#container) unless it's configured with Group ID, which is needed for the [OIDC authentication service](https://github.com/arrikto/oidc-authservice) and Kubeflow Jupyter server. - -Therefore, you're recommended to set up the default storage class with Group ID support so that you can get the best experience from Kubeflow. - -1. Set the File Storage with Group ID support as the default storage class. - - ```shell - NEW_STORAGE_CLASS=ibmc-file-gold-gid - OLD_STORAGE_CLASS=$(kubectl get sc -o jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io\/is-default-class=="true")].metadata.name}') - kubectl patch storageclass ${NEW_STORAGE_CLASS} -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' - - # List all the (default) storage classes - kubectl get storageclass | grep "(default)" - ``` - - Example output: - ``` - ibmc-file-gold-gid (default) ibm.io/ibmc-file Delete Immediate false 14h - ``` - -2. Make sure `ibmc-file-gold-gid` is the only `(default)` storage class. If there are two or more rows in the above output, unset the previous `(default)` storage classes with the command below: - ```shell - kubectl patch storageclass ${OLD_STORAGE_CLASS} -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' - ``` - -### Storage setup for **vpc-gen2** IBM Cloud Kubernetes cluster - -**Note**: To deploy Kubeflow, you don't need to change the storage setup for `vpc-gen2` Kubernetes cluster. - -Currently, there is no option available for setting up RWX (read-write multiple nodes) type of storages. -RWX is not a mandatory requirement to run Kubeflow and most pipelines. -It is required by certain sample jobs/pipelines where multiple pods write results to a common storage. -A job or a pipeline can also write to a common object storage like `minio`, so the absence of this feature is -not a blocker for working with Kubeflow. -Examples of jobs/pipelines that will not work, are: -[Distributed training with Kubeflow TFJob](https://github.com/kubeflow/training-operator/tree/master/examples/tensorflow/mnist_with_summaries) - -If you are on `vpc-gen2` and still need RWX, you may try [portworx enterprise product](https://portworx.com/products/features/). -To set it up on IBM Cloud use the [portworx install with IBM Cloud](https://docs.portworx.com/portworx-install-with-kubernetes/cloud/ibm/) guide. - - -## Installation - -Choose either **single user** or **multi-tenant** section based on your usage. - -If you're experiencing issues during the installation because of conflicts on your Kubeflow deployment, you can [uninstall Kubeflow](/docs/ibm/deploy/uninstall-kubeflow) and install it again. - -## Single user - -Using kustomize together with kubectl to deploy kubeflow: - -1. Clone the manifest repo as follows: - - ```shell - git clone https://github.com/IBM/manifests.git -b v1.7-branch ibm-manifests-17 - ``` - -2. Change directory to `ibm-manifests-17`: - - ```shell - cd ibm-manifests-17 - ``` - -3. Generate password for default user: `user@example.com` - ```shell - python3 -c 'from passlib.hash import bcrypt; import getpass; print(bcrypt.using(rounds=12, ident="2y").hash(getpass.getpass()))' - ``` - Type your password and press `` after you see `Password:` prompt. Copy the hash code for next step. - -4. Edit `dist/stacks/ibm/application/dex-auth/custom-env.yaml` and fill the relevant field - with the hash code from previous step: - ``` - staticPasswords: - - email: user@example.com - hash: - ``` - You can also change the email value if needed. - -5. Apply the `kustomize` file under `iks-single` folder for single user deployment: - - ```shell - while ! kustomize build iks-single 2>/dev/null | awk '!/well-defined/' | kubectl apply -f -; do echo "Retrying to apply resources"; sleep 10; done - ``` - -### Accessing your cluster - -The Kubeflow endpoint is exposed with [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport) `30380`. To get a static ip, you can [expose the Kubeflow endpoint as a LoadBalancer](#expose-the-kubeflow-endpoint-as-a-loadbalancer) and access the **EXTERNAL_IP**. - -For single-user Kubeflow, IBM Cloud uses Dex authentication by default. You can access the cluster using -the email and password you specified in step 3 and 4 of [Single User](#single-user) - -## Multi-user, auth-enabled - -Run the following steps to deploy Kubeflow with [IBM Cloud AppID](https://cloud.ibm.com/catalog/services/app-id) -as an authentication provider. - -The scenario is a Kubeflow cluster admin configures Kubeflow as a web -application in AppID and manages user authentication with builtin identity -providers (Cloud Directory, SAML, social log-in with Google or Facebook etc.) or -custom providers. - -### Prerequisites - -For authentication, IBM Cloud uses [AppID](https://cloud.ibm.com/catalog/services/app-id) - -1. Follow the [Creating an App ID service instance on IBM Cloud](https://cloud.ibm.com/catalog/services/app-id) guide to learn about Kubeflow authentication. -You can also learn [how to use App ID](https://cloud.ibm.com/docs/appid?topic=appid-getting-started) with different authentication methods. - -2. Follow the [Registering your app](https://cloud.ibm.com/docs/appid?topic=appid-app#app-register) - section of the App ID guide to create an application with type - _regularwebapp_ under the provisioned AppID instance. Make sure the _scope_ - contains _email_. Then retrieve the following configuration parameters from your AppID: - * `clientId` - * `secret` - * `oAuthServerUrl` - - You will be using these information in the subsequent sections. - -3. Register the Kubeflow OIDC redirect page. The Kubeflow `REDIRECT_URL` URL is - `[http|https]:///authservice/oidc/callback`, depends on if you enable the HTTPS or not. - `` is the endpoint for accessing Kubeflow. By default, the `` - on IBM Cloud is `:30380`. To get a static ip, you can - [expose the Kubeflow endpoint as a LoadBalancer](#expose-the-kubeflow-endpoint-as-a-loadbalancer) - and use the **EXTERNAL_IP** for your ``. Or use `ibmcloud ks nlb-dns` command - to map the **EXTERNAL_IP** to the generated FQDN for your cluster. In this case, you use the - generated FQDN as `kubeflow-FQDN`. If you enable HTTPS, you shall use generated FQDN. - -4. Then, you need to place the Kubeflow OIDC `REDIRECT_URL` under **Manage Authentication** > **Authentication settings** > **Add web redirect URLs**. - - APP ID Redirect Settings - - Example: - `https://my-kubeflow-442dbba0442be6c8c50f31ed96b00601-0000.sjc04.containers.appdomain.cloud/authservice/oidc/callback` -### Deploy: Using kustomize together with kubectl - -1. Clone the manifest repo as follows: - - ```shell - git clone https://github.com/IBM/manifests.git -b v1.7-branch ibm-manifests-17 - ``` - -2. Change directory to `ibm-manifests-17`: - - ```shell - cd ibm-manifests-17 - ``` - -3. Update the `dist/stacks/ibm/application/oidc-authservice-appid/params.env` - with values collected in [Prereq](#prerequisites-1) section. - You will need the following values: - * `` - replace `` - * `` - fill in the FQDN of Kubeflow, if you don't know yet, just give a dummy one like - `localhost`. Then change it after you got one. Or get default FQDN of your cluster by this command: - `ibmcloud ks nlb-dns ls -c ` (replace `` with your cluster name) - - Example: - ``` - OIDC_PROVIDER=https://us-south.appid.cloud.ibm.com/oauth/v4/f341ff8b-a088-497a-same-5da4628df7fd - REDIRECT_URL=https://my-kubeflow-442dbba0442be6c8c50f31ed96b00601-0000.sjc04.containers.appdomain.cloud/authservice/oidc/callback - OIDC_AUTH_URL=https://us-south.appid.cloud.ibm.com/oauth/v4/f341ff8b-a088-497a-same-5da4628df7fd/authorization - ``` - -4. Update the `dist/stacks/ibm/application/oidc-authservice-appid/secret_params.env` - with values collected in [Prereq](#prerequisites-1) section. - You will need the following values: - * `` - replace the `` - * `` - replace the `` - - Example: - ``` - CLIENT_SECRET=NjNhZDA3ODAtM2I3MCSECRETLTkwN2QtNDdhYmU5ZGIyMTBl - CLIENT_ID=52b3e496-8888-8888-ABC9-c0da309cdf52 - ``` - -5. You can apply the `kustomize` file in `iks-multi` folder: - - ```bash - while ! kustomize build iks-multi 2>/dev/null | awk '!/well-defined/' | kubectl apply -f -; do echo "Retrying to apply resources"; sleep 10; done - ``` - -6. If at any point the values change and you have to change them, you can either patch the - [configmap](#patch-configmap) and [secret](#patch-secret) or change the content in the - files and apply the kustomize again. You will need to restart authservice with - `kubectl delete pod -l app=authservice -n istio-system` . - - To apply just the `oidc-authservice-appid` you can use this command: - - ```bash - kustomize build dist/stacks/ibm/application/oidc-authservice-appid | kubectl apply -f - - kubectl delete pod -l app=authservice -n istio-system - ``` - -### Verify mutli-user installation - -Check the pod `authservice-0` is in running state in namespace `istio-system`: - -```SHELL -kubectl get pod -l app=authservice -n istio-system -``` - -### Extra network setup requirement for **vpc-gen2** clusters only - -**Note**: These steps are not required for `classic` clusters, i.e. where `WORKER_NODE_PROVIDER` is set to `classic`. - -A `vpc-gen2` cluster does not assign a public IP address to the Kubernetes master node by default. -It provides access via a Load Balancer, which is configured to allow only a set of ports over public internet. -Access the cluster's resources in a `vpc-gen2` cluster, using one of the following options, - -* Load Balancer method: To configure via a Load Balancer, go to [Expose the Kubeflow endpoint as a LoadBalancer](#expose-the-kubeflow-endpoint-as-a-loadbalancer). - This method is recommended when you have Kubeflow deployed with [Multi-user, auth-enabled](#multi-user-auth-enabled) support — otherwise it will expose - cluster resources to the public. - -* Socks proxy method: If you need access to nodes or NodePort in the `vpc-gen2` cluster, this can be achieved by starting another instance in the -same `vpc-gen2` cluster and assigning it a public IP (i.e. the floating IP). Next, use SSH to log into the instance or create an SSH socks proxy, - such as `ssh -D9999 root@new-instance-public-ip`. - -Then, configure the socks proxy at `localhost:9999` and access cluster services. - -* `kubectl port-forward` method: To access Kubeflow dashboard, run `kubectl -n istio-system port-forward service/istio-ingressgateway 7080:http2`. - Then in a browser, go to[http://127.0.0.1:7080/](http://127.0.0.1:7080/) - -_**Important notice**: Exposing cluster/compute resources publicly without setting up a proper user authentication mechanism -is very insecure and can have very serious consequences(even legal). If there is no need to expose cluster services publicly, -Socks proxy method or `kubectl port-forward` method are recommended._ - -## Next steps: secure the Kubeflow dashboard with HTTPS - -### Prerequisites - -For both `classic` and `vpc-gen2` cluster providers, make sure you have [Multi-user, auth-enabled](#multi-user-auth-enabled) Kubeflow set up. - -### Setup - -Follow the steps in [Exposing the Kubeflow dashboard with DNS and TLS termination](../authentication/#exposing-the-kubeflow-dashboard-with-dns-and-tls-termination). -Then, you will have the required DNS name as Kubeflow FQDN to enable the OIDC flow for AppID: - - -1. Follow the step [Adding redirect URIs](https://cloud.ibm.com/docs/appid?topic=appid-managing-idp#add-redirect-uri) - to fill a URL for AppID to redirect to Kubeflow. The URL should look like `https:///authservice/oidc/callback`. - -2. Update the secret `appid-application-configuration` with the updated Kubeflow FQDN to replace `` in below command: - - ```SHELL - export REDIRECT_URL=https:///authservice/oidc/callback - export PATCH=$(printf '{"data": {"REDIRECT_URL": "%s"}}' "$REDIRECT_URL") - - kubectl patch configmap/oidc-authservice-parameters -n istio-system -p="$PATCH" - ``` - -3. Restart the pod `authservice-0`: - - ```shell - kubectl delete pod -l app=authservice -n istio-system - ``` - -Then, visit `https:///`. The page should redirect you to AppID for authentication. - -## Troubleshooting - -### Expose the Kubeflow endpoint as a LoadBalancer - -By default, the Kubeflow deployment on IBM Cloud only exposes the endpoint as [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport) 30380. If you want to expose the endpoint as a [LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), run: - -```shell -kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec": {"type": "LoadBalancer"}}' -``` - -Then, you can locate the LoadBalancer in the **EXTERNAL_IP** column when you run the following command: - -```shell -kubectl get svc istio-ingressgateway -n istio-system -``` - -There is a small delay, usually ~5 mins, for above commands to take effect. - -### Authservice pod taking too long to restart - -You might see the `authservice-0` pod taking some time to restart. If that happens you can delete to pod which will kick off restart from kubernetes reconciler. - -```bash -kubectl delete pod -l app=authservice -n istio-system -``` diff --git a/content/en/docs/distributions/ibm/deploy/uninstall-kubeflow.md b/content/en/docs/distributions/ibm/deploy/uninstall-kubeflow.md deleted file mode 100644 index 3392ec0d16..0000000000 --- a/content/en/docs/distributions/ibm/deploy/uninstall-kubeflow.md +++ /dev/null @@ -1,43 +0,0 @@ -+++ -title = "Uninstall Kubeflow" -description = "Instructions for uninstalling Kubeflow" -weight = 20 - -+++ - -Uninstall Kubeflow on your IBM Cloud IKS cluster. - -1. Go to your Kubeflow deployment directory where you download the - IBM manifests repository: https://github.com/IBM/manifests.git - ```shell - cd ibm-manifests-17 - ``` - -2. Run the following command to get Kubeflow Profiles: - ```shell - kubectl get profile - ``` - -3. Delete all Kubeflow Profiles manually: - ```shell - kubectl delete profile --all - ``` - Use the following command to check all namespaces for Kubeflow Profiles - are removed properly: - ``` - kubectl get ns - ``` - Make sure no namespace is in the `Terminating` state. - - -4. Remove Kubeflow: - - For single-user deployment: - ```shell - kustomize build iks-single 2>/dev/null | awk '!/well-defined/' | kubectl delete -f - - ``` - - For multi-user deployment: - ```shell - kustomize build iks-multi 2>/dev/null | awk '!/well-defined/' | kubectl delete -f - - ``` diff --git a/content/en/docs/distributions/ibm/iks-e2e.md b/content/en/docs/distributions/ibm/iks-e2e.md deleted file mode 100644 index ef3c4a8066..0000000000 --- a/content/en/docs/distributions/ibm/iks-e2e.md +++ /dev/null @@ -1,86 +0,0 @@ -+++ -title = "End-to-end Kubeflow on IBM Cloud" -description = "Running Kubeflow using IBM Cloud Kubernetes Service (IKS)" -weight = 7 - -+++ -This is a guide for an end-to-end example of Kubeflow on [IBM Cloud Kubernetes Service (IKS)](https://cloud.ibm.com/docs/containers?topic=containers-getting-started). The core steps will be to take a base Tensorflow model, modify it for distributed training, serve the resulting model with TFServing, and deploy a web application that uses the trained model. - -## Introduction -### Overview of IKS - -[IBM Cloud Kubernetes Service (IKS)](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) enables the deployment of containerized applications in Kubernetes clusters with specialized tools for management of the systems. - -The [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cloud-cli-getting-started) can be used for creating, developing, and deploying cloud applications. - -Here's a list of IBM Cloud services you will use: -* [IKS][iks] -* [IBM Cloud Object Storage][ibm-cos] - -### The model and the data - -This tutorial trains a [TensorFlow][tensorflow] model on the -[MNIST dataset][mnist-data], which is the *hello world* for machine learning. - -The MNIST dataset contains a large number of images of hand-written digits in -the range 0 to 9, as well as the labels identifying the digit in each image. - -After training, the model can classify incoming images into 10 categories -(0 to 9) based on what it's learned about handwritten images. In other words, -you send an image to the model, and the model does its best to identify the -digit shown in the image. -Prediction UI - -In the above screenshot, the image shows a hand-written **7**. This image was -the input to the model. The table below the image shows a bar graph for each -classification label from 0 to 9, as output by the model. Each bar -represents the probability that the image matches the respective label. -Judging by this screenshot, the model seems pretty confident that this image -is a 7. - -### The overall workflow - -The following diagram shows what you accomplish by following this guide: - -ML workflow for training and serving an MNIST model - -In summary: - -* Setting up [Kubeflow][kubeflow] on [IKS][iks]. -* Training the model: - * Packaging a Tensorflow program in a container. - * Submitting a Tensorflow training ([tf.train][tf-train]) job. -* Using the model for prediction (inference): - * Saving the trained model to [IBM Cloud Object Storage][ibm-cos]. - * Using [Tensorflow Serving][tf-serving] to serve the model. - * Running the simple web app to send prediction request to the model and display the result. - -It's time to get started! - -## Run the MNIST Tutorial on IKS - -1. Follow the [IKS instructions](/docs/ibm/deploy/install-kubeflow) to deploy Kubeflow. -2. Launch a Jupyter notebook. -3. Launch a terminal in Jupyter and clone the Kubeflow examples repo. - ``` - git clone https://github.com/kubeflow/examples.git git_kubeflow-examples - ``` - * **Tip**: When you start a terminal in Jupyter, run the command `bash` to start - a bash terminal which is much more friendly than the default shell. - * **Tip**: You can change the URL for your notebook from '/tree' to '/lab' to switch to using Jupyterlab. -4. Open the notebook `mnist/mnist_ibm.ipynb`. -5. Follow the notebook to train and deploy MNIST on Kubeflow. - - -[kubernetes]: https://kubernetes.io/ -[kubeflow]: https://www.kubeflow.org/ -[iks]: https://www.ibm.com/cloud/container-service/ -[ibm-cos]: https://www.ibm.com/cloud/object-storage -[mnist-data]: https://yann.lecun.com/exdb/mnist/index.html -[tensorflow]: https://www.tensorflow.org/ -[tf-train]: https://www.tensorflow.org/api_guides/python/train -[tf-serving]: https://www.tensorflow.org/tfx/guide/serving diff --git a/content/en/docs/distributions/ibm/kfp-tekton.png b/content/en/docs/distributions/ibm/kfp-tekton.png deleted file mode 100644 index 4b8928a837..0000000000 Binary files a/content/en/docs/distributions/ibm/kfp-tekton.png and /dev/null differ diff --git a/content/en/docs/distributions/ibm/pipelines.md b/content/en/docs/distributions/ibm/pipelines.md deleted file mode 100644 index 2c3935b4bf..0000000000 --- a/content/en/docs/distributions/ibm/pipelines.md +++ /dev/null @@ -1,160 +0,0 @@ -+++ -title = "Pipelines on IBM Cloud Kubernetes Service (IKS)" -description = "Instructions for using Kubeflow Pipelines on IBM Cloud Kubernetes Service (IKS)" -weight = 5 -+++ - -By default, Kubeflow Pipelines on IBM Cloud are running with the Tekton backend. In this guide you'll learn how to use the Kubeflow Pipelines with the Tekton backend [(kfp-tekton)](https://github.com/kubeflow/kfp-tekton). This assumes you have deployed [Kubeflow on IBM Cloud using the instructions on this website](https://www.kubeflow.org/docs/ibm/deploy/). - -You can also do a [standalone installation of Kubeflow Pipelines with Tekton](https://github.com/kubeflow/kfp-tekton/blob/master/guides/kfp_tekton_install.md#standalone-kubeflow-pipelines-with-tekton-backend-deployment) if you don't want whole of Kubeflow. - -KFP-Tekton - -In this tutorial, we use the below single step pipeline as our example - -```python -from kfp import dsl -def echo_op(): - return dsl.ContainerOp( - name='echo', - image='busybox', - command=['sh', '-c'], - arguments=['echo "Got scheduled"'] - ) - -@dsl.pipeline( - name='echo', - description='echo pipeline' -) -def echo_pipeline( -): - echo = echo_op() -``` - -# Declare the Python Client for Kubeflow Pipelines - -## 1. Single-user Kubeflow Pipelines deployment with the SDK - -* You will be using the Kubeflow Pipelines with Tekton SDK ([`kfp-tekton`](https://pypi.org/project/kfp-tekton/)) v0.4.0 or above. -* If you have deployed Kubeflow on IBM Cloud using the -[`kfctl_ibm.v1.2.0.yaml`](https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_ibm.v1.2.0.yaml) -manifest you can configure ([`kfp-tekton`](https://pypi.org/project/kfp-tekton/)) SDK to list all your Kubeflow Pipelines experiments as follows: - -```python -from kfp_tekton import TektonClient - -KUBEFLOW_PUBLIC_ENDPOINT_URL = 'http://' -KUBEFLOW_PROFILE_NAME = None -client = TektonClient(host=f'{KUBEFLOW_PUBLIC_ENDPOINT_URL}/pipeline') - -experiments = client.list_experiments(namespace=KUBEFLOW_PROFILE_NAME) -``` -**Note**: `` is the EXTERNAL_IP you exposed as a LoadBalancer following [`this instruction`](https://www.kubeflow.org/docs/ibm/deploy/install-kubeflow-on-iks/#expose-the-kubeflow-endpoint-as-a-loadbalancer). If you have not done that step during Kubeflow setup, please include port 31380 because the Kubeflow endpoint is exposed with NodePort 31380. - -## 2. Authenticating multi-user Kubeflow Pipelines with the SDK - -* You will be using the Kubeflow Pipelines SDK ([`kfp-tekton`](https://pypi.org/project/kfp-tekton/)) v0.4.0 or above. -* Note that this feature is available with multi-user, auth-enabled Kubeflow installation deployed from the [`kfctl_ibm_multi_user.v1.2.0.yaml`](https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_ibm_multi_user.v1.2.0.yaml) -manifest. - -**Note**: You're highly recommended enabling HTTPS for the public endpoint of Kubeflow because this method transports sensitive information like session cookie values over edge network. - -It requires authentication via the public endpoint of Kubeflow deployment when using the Kubeflow Pipelines multi-user feature with Pipelines SDK. - -You need to provide the following three variables if you're using an in-cluster Jupyter notebook or a remote client machine: - -1. `KUBEFLOW_PUBLIC_ENDPOINT_URL` - Kubeflow public endpoint URL. You can obtain it from command `ibmcloud ks nlb-dns ls --cluster `. -1. `SESSION_COOKIE` - A session cookie starts with `authservice_session=`. You can obtain it from your browser after authenticated from Kubeflow UI. Notice that this session cookie expires in 24 hours, so you need to obtain it again after cookie expired. -1. `KUBEFLOW_PROFILE_NAME` - Your Kubeflow profile name - -Once you provide the three variables, the SDK can use the following Python code to list all your Kubeflow Pipelines experiments: - -```python -from kfp_tekton import TektonClient - -KUBEFLOW_PUBLIC_ENDPOINT_URL = 'https://xxxx..containers.appdomain.cloud' -# this session cookie looks like "authservice_session=xxxxxxx" -SESSION_COOKIE = 'authservice_session=xxxxxxx' -KUBEFLOW_PROFILE_NAME = '' - -client = TektonClient( - host=f'{KUBEFLOW_PUBLIC_ENDPOINT_URL}/pipeline', - cookies=SESSION_COOKIE -) - -experiments = client.list_experiments(namespace=KUBEFLOW_PROFILE_NAME) -``` - -Pipelines components like experiments and runs are isolated by Kubeflow profiles. A Kubeflow user can only see Pipelines experiments and runs belonging to this user's Kubeflow profile. - -# Upload pipelines - -Once you have declared the Python client, your Kubeflow pipelines can be uploaded using Python. - -Run the following code inside a Python session to upload the pipelines. This example shows different versions of the pipeline using the Python client. - -```python -import os - -# Initial version of the compiled pipeline -pipeline_file_path = 'echo_pipeline.yaml' -pipeline_name = 'echo_pipeline' - -# For the purpose of this tutorial, we will be using the same pipeline for both version. -pipeline_version_file_path = 'echo_pipeline.yaml' -pipeline_version_name = 'new_echo_pipeline' - -# Upload initial version of the pipeline -pipeline_file = os.path.join(pipeline_file_path) -pipeline = client.pipeline_uploads.upload_pipeline(pipeline_file, name=pipeline_name) - -# Upload new version of the pipeline -pipeline_version_file = os.path.join(pipeline_version_file_path) -pipeline_version = client.pipeline_uploads.upload_pipeline_version(pipeline_version_file, - name=pipeline_version_name, - pipelineid=pipeline.id) -``` - -# Run pipelines from the SDK -The `TektonClient` can run pipelines using one of the below sources: - -1. [Python DSL source code](#run-pipelines-from-the-python-dsl-source-code) -2. [Compiled pipeline file](#run-pipelines-from-the-compiled-pipeline-file) -3. [Uploaded pipelines on KFP engine](#run-pipelines-from-the-list-of-uploaded-pipelines) - -## Run pipelines from the Python DSL source code - -To learn about executing pipelines using the Python DSL source code, try the code below in a Python session using the `echo_pipeline` example. -The `create_run_from_pipeline_func` takes the DSL source code to compile and run it directly using the Kubeflow pipeline API without -uploading it to the pipeline list. This method is recommended if you are doing quick experiments without version control. - -```python -# You can overwrite the pipeline default parameters by providing a dictionary of key-value arguments. -# If you don't want to overwrite the default parameters, then define the arguments as an empty dictionary. -arguments={} - -client.create_run_from_pipeline_func(echo_pipeline, arguments=arguments, namespace=KUBEFLOW_PROFILE_NAME) -``` - -## Run pipelines from the compiled pipeline file - -Alternatively, you can also run the pipeline directly using a pre-compiled file. -```python -EXPERIMENT_NAME = 'Demo Experiments' -experiment = client.create_experiment(name=EXPERIMENT_NAME, namespace=KUBEFLOW_PROFILE_NAME) -run = client.run_pipeline(experiment.id, 'echo-pipeline', 'echo_pipeline.yaml') -``` - -## Run pipelines from the list of uploaded pipelines - -Similarly, you can also run the pipeline from the list of uploaded pipelines using the same `run_pipeline` function. - -```python -EXPERIMENT_NAME = 'Demo Experiments' -experiment = client.create_experiment(name=EXPERIMENT_NAME, namespace=KUBEFLOW_PROFILE_NAME) - -# Find the pipeline ID that you want to use. -client.list_pipelines() - -run = client.run_pipeline(experiment.id, pipeline_id='925415d5-18e9-4e08-b57f-3b06e3e54648', job_name='echo_pipeline_run') -``` diff --git a/content/en/docs/distributions/ibm/using-icr.md b/content/en/docs/distributions/ibm/using-icr.md deleted file mode 100644 index 4896205928..0000000000 --- a/content/en/docs/distributions/ibm/using-icr.md +++ /dev/null @@ -1,80 +0,0 @@ -+++ -title = "Using IBM Cloud Container Registry (ICR)" -description = "This guide covers certain scenarios involving using private container images with the IBM Cloud Container Registry (ICR)." -weight = 6 -+++ - -## Prerequisites - -* Install and configure the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started). -* Install the CLI plug-in for the IBM Cloud Container Registry by running the command `ibmcloud plugin install container-registry`. -* Create a namespace in ICR with the command `ibmcloud cr namespace-add `, replace `` with your preferred name. - -**Note**: The [ICR namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started#gs_registry_namespace_add) is different from the Kubeflow Profile namespace. The ICR namespace is used to group container images stored in ICR, while a [Kubeflow Profile](/docs/components/multi-tenancy/overview/) namespace is a group of all Kubernetes clusters owned by a user. - -## Image pull secret - -As a Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with a container registry to pull a private image, it needs an image pull secret to pull container images from IBM Cloud Container Registry. You can use the default image pull secret set up by the cluster or your account's IAM API key. - -### Using a default image pull secret - -By default, the IBM Cloud Kubernetes cluster is set up to pull images from only your account's namespace in IBM Cloud Container Registry by using the secret `all-icr-io` in the `default` namespace. A cluster admin can copy this secret to any Kubernetes namespace used as Kubeflow profile. For example, run below command to copy the secret `all-icr-io` to the `anonymous` namespace: - -``` -kubectl get secret all-icr-io -n default -o yaml \ -| sed 's/namespace: default/namespace: anonymous/g' \ -| kubectl -n anonymous create -f - -``` - -Once this secret is ready in your Kubeflow profile, a data scientist can use it to pull container images from ICR. - -See details and FAQs from the official guide [Setting up an image registry](https://cloud.ibm.com/docs/containers?topic=containers-registry). - -### Getting an IAM API Key - -You will need an IBM Cloud IAM API Key to work with ICR if you: -1. Have no access to the default image pull secret `all-icr-io` from the `default` namespace. -2. Need to access container images in other IBM Cloud accounts. -3. Need customized IAM policy by using a separate IAM service ID. - -If you don't have an IBM Cloud IAM API Key, follow the official guide [Create an API Key](https://cloud.ibm.com/docs/account?topic=account-userapikey#create_user_key). - -Once you get your IBM Cloud IAM API Key, run the following command: - -``` -kubectl -n create secret docker-registry \ ---docker-server= \ ---docker-username=iamapikey \ ---docker-password= \ ---docker-email= -``` - -**Notes**: -* ``: your namespace to use with ICR to create an image pull secret. -* ``: your IBM Cloud API Key. -* ``: a unique name for the pull image secret, such as `us-icr-io`, for example. -* ``: the image registry where your registry namespace is set up. Use regional domain name when storing container images in specific region, such as `us.icr.io` when using region `en-us` and `uk.icr.io` when using region `eu-gb`. See full list of regional domain names from the [About IBM Cloud Container Registry page](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overview#registry_regions_local). -* ``: your docker email address or any fictional email address, such as `a@b.c`. - -## Scenarios - -### Using container images from ICR in Kubeflow Pipelines - -The pull image secret may be set in Kubeflow Pipelines SDK's [`PipelineConf`](https://kubeflow-pipelines.readthedocs.io/en/stable/source/kfp.dsl.html#kfp.dsl.PipelineConf). Refer to this [`imagepullsecrets.py`](https://github.com/kubeflow/pipelines/blob/ef381aafccf916482d16774cac3b8568d06dff9e/samples/core/imagepullsecrets/imagepullsecrets.py#L55) sample in Kubeflow Pipelines project for usage. - -### Using notebook images from ICR in a Jupyter Notebook - -When a namespace is created for Kubeflow with its profile controller, a default service account `default-editor` is created in that namespace. Before creating a Notebook Server, run following command to patch the service account. Replace `` with the ICR pull image secret name and `` with the Kubeflow profile namespace. - -Replace `` with your namespace then run below command to patch the service account `default-editor` with this image pull secret: -```SHELL -kubectl patch serviceaccount default-editor \ --p '{"imagePullSecrets": [{"name": ""}]}' \ --n -``` - -The service account should be updated. Then, when you create the Notebook Server through Kubeflow dashboard, you should be able to choose a Custom Image. Afterwards, set the notebook image path from the ICR as follows: - -Notebook Custom Image