diff --git a/doc/source/admintasks/kubernetes-admin-tutorials-helm-package-manager.rst b/doc/source/admintasks/kubernetes-admin-tutorials-helm-package-manager.rst index e94d46a7d..9482f0eaa 100644 --- a/doc/source/admintasks/kubernetes-admin-tutorials-helm-package-manager.rst +++ b/doc/source/admintasks/kubernetes-admin-tutorials-helm-package-manager.rst @@ -6,9 +6,8 @@ Helm Package Manager ==================== -|prod-long| supports Helm with Tiller, the Kubernetes package manager that -can be used to manage the lifecycle of applications within the Kubernetes -cluster. +|prod-long| supports Helm v3 package manager for Kubernetes that can be used to +securely manage the lifecycle of applications within the Kubernetes cluster. .. rubric:: |context| @@ -18,26 +17,30 @@ your Kubernetes applications using Helm charts. Helm charts are defined with a default set of values that describe the behavior of the service installed within the Kubernetes cluster. -Upon system installation, the official curated Helm chart repository is added -to the local Helm repo list, in addition, a number of local repositories -\(containing optional |prod-long| packages\) are created and added to the Helm -repo list. For more information, -see `https://github.com/helm/charts `__. +A Helm v3 client is installed on controllers for local use by admins to manage +end-users' Kubernetes applications. |prod| recommends to install a Helm v3 +client on a remote workstation, so that non-admin (and admin) end-users can +manage their Kubernetes applications remotely. -Use the following command to list the Helm repositories: +Upon system installation, local Helm repositories \(containing |prod-long| +packages\) are created and added to the Helm repo list. + +Use the following command to list these local Helm repositories: .. code-block:: none ~(keystone_admin)]$ helm repo list NAME URL - stable `https://kubernetes-charts.storage.googleapis.com`__ - local `http://127.0.0.1:8879/charts`__ - starlingx `http://127.0.0.1:8080/helm_charts/starlingx`__ - stx-platform `http://127.0.0.1:8080/helm_charts/stx-platform`__ + starlingx `http://127.0.0.1:8080/helm_charts/starlingx` + stx-platform `http://127.0.0.1:8080/helm_charts/stx-platform` -For more information on Helm, see the documentation at `https://helm.sh/docs/ `__. +Where the `stx-platform` repo holds helm charts of StarlingX Applications \(see +next section\) of the |prod| platform itself, while the `starlingx` repo holds +helm charts of optional StarlingX applications, such as Openstack. The admin +user can add charts to these local repos and regenerate the index to use these +charts, and add new remote repositories to the list of known repos. -**Tiller** is a component of Helm. Tiller interacts directly with the -Kubernetes API server to install, upgrade, query, and remove Kubernetes -resources. +For more information on Helm v3, see the documentation at `https://helm.sh/docs/ `__. +For more information on how to configure and use Helm both locally and remotely, see :ref:`Configure Local CLI Access `, +and :ref:`Configure Remote CLI Access `. diff --git a/doc/source/container_integration/kubernetes/create-test-and-terminate-a-ptp-notification-demo.rst b/doc/source/container_integration/kubernetes/create-test-and-terminate-a-ptp-notification-demo.rst deleted file mode 100644 index 80ced2b85..000000000 --- a/doc/source/container_integration/kubernetes/create-test-and-terminate-a-ptp-notification-demo.rst +++ /dev/null @@ -1,164 +0,0 @@ - -.. jff1614105111370 -.. _create-test-and-terminate-a-ptp-notification-demo: - -=================================================== -Create, Test, and Terminate a PTP Notification Demo -=================================================== - -This section provides instructions on accessing, creating, testing and -terminating a **ptp-notification-demo**. - -.. rubric:: |context| - - -Use the following procedure to copy the tarball from |dnload-loc|, create, test, -and terminate a ptp-notification-demo. - -.. rubric:: |proc| - - -.. _create-test-and-terminate-a-ptp-notification-demo-steps-irz-5w4-t4b: - -#. Copy the **ptp-notification-demo\_v1.0.2.tgz** file from |prod-long| - at `http://mirror.starlingx.cengn.ca/mirror/starlingx/ - `__ to yor system, and extract its content. - - .. note:: - The tarball includes the docker file and code to build the reference - API application, and the Helm chart to install the Sidecar along with - the application. - - The following files are part of the tarball: - - - - Helm charts - - - - Chart.yaml - - - values.yaml - - - \_helpers.tpl - - - configmap.yaml - - - deployment.yaml - - - .helmignore - - - ptp-notification-override.yaml - - - app\_start.sh - - - sidecar\_start.sh - - - - notification-docker - - - - Dockerfile - - - api - - - - .. note:: - The demo uses the following images: - - - - starlingx/notificationclient-base:stx.5.0-v1.0.3 - - - ptp-base:1.0.1 - - -#. Build the **ptp-base:1.0.1** image using the following commands. - - .. code-block:: none - - $ tar xvf ptp-notification-demo_.tgz - $ cd ~/notification-dockers/ptp-base/ - $ sudo docker build . -t ptp-base:1.0.1 - $ sudo docker save ptp-base:1.0.1 -o ptp-base.1.0.1.tar - $ sudo ctr -n k8s.io image import ./ptp-base.1.0.1.tar - $ cd ~/charts - $ tar xvf ptp-notification-demo-1.tgz - - .. note:: - For |AIO|-SX and AIO-DX systems, ptp-base.1.0.1.tar should be copied to - each node and the import command, :command:`sudo ctr -n k8s.io image - import ./ptp-base.1.0.1.tar` should be run on each node. - -#. Install the demo's pod using the following commands. - - .. note:: - This pod includes two containers, Sidecar and the referenced API - application. - - .. code-block:: none - - $ kubectl create namespace ptpdemo - $ helm install -n notification-demo ~/charts/ptp-notification-demo -f ~/charts/ptp-notification-demo/ptp-notification-override.yaml - $ kubectl get pods -n ptpdemo - - .. code-block:: none - - NAME READY STATUS RESTARTS AGE - notification-demo-ptp-notification-demo-cf7b65c47-s5jk6 2/2 Running 0 5m50s - -#. Test the **ptp-notification** demo. - - - #. Display the app logs using the following command. - - .. code-block:: none - - $ kubectl logs -f notification-demo-ptp-notification-demo- -c ptp-notification-demo-app -n ptpdemo - - -#. In another terminal, access the application container. - - .. code-block:: none - - $ kubectl exec -it notification-demo-ptp-notification-demo- -c ptp-notification-demo-app -n ptpdemo -- bash - - - #. Check if you can pull |PTP| status using the REST API. - - .. code-block:: none - - $ curl -v -H 'Content-Type: application/json' http://127.0.0.1:8080/ocloudNotifications/v1/PTP/CurrentState - - #. Subscribe to |PTP| notifications. - - .. code-block:: none - - $ curl -v -d '{"ResourceType": "PTP", "ResourceQualifier": {"NodeName": "controller-0"}, "EndpointUri": "http://127.0.0.1:9090/v1/resource_status/ptp"}' -H 'Content-Type: application/json' -X POST http://127.0.0.1:${SIDECAR_API_PORT}/ocloudNotifications/v1/subscriptions |python -m json.tool - - #. Retrieve a list of subscriptions. - - .. code-block:: none - - $ curl -v -H 'Content-Type: application/json' http://127.0.0.1:${SIDECAR_API_PORT}/ocloudNotifications/v1/subscriptions |python -m json.tool - - For example, to get a specific subscription, use the following command. - - .. code-block:: none - - $ curl -v -H 'Content-Type: application/json' http://127.0.0.1:${SIDECAR_API_PORT}/ocloudNotifications/v1/subscriptions/ - - #. To delete a specific subscription with the subscription ID, run the - following command. - - .. code-block:: none - - $ curl -X DELETE -v -H 'Content-Type: application/json' http://127.0.0.1:${SIDECAR_API_PORT}/ocloudNotifications/v1/subscriptions/ - - -#. Terminate the demo using the following command. - - .. code-block:: none - - $ helm del --purge notification-demo - - diff --git a/doc/source/container_integration/kubernetes/index.rst b/doc/source/container_integration/kubernetes/index.rst index e8869feb5..e60b7a7c9 100644 --- a/doc/source/container_integration/kubernetes/index.rst +++ b/doc/source/container_integration/kubernetes/index.rst @@ -14,6 +14,3 @@ PTP Notification remove-ptp-notifications override-default-application-values integrate-the-application-with-notification-client-sidecar - create-test-and-terminate-a-ptp-notification-demo - - diff --git a/doc/source/container_integration/kubernetes/integrate-the-application-with-notification-client-sidecar.rst b/doc/source/container_integration/kubernetes/integrate-the-application-with-notification-client-sidecar.rst index 1d5a15c79..ca8a56434 100644 --- a/doc/source/container_integration/kubernetes/integrate-the-application-with-notification-client-sidecar.rst +++ b/doc/source/container_integration/kubernetes/integrate-the-application-with-notification-client-sidecar.rst @@ -41,12 +41,3 @@ The following prerequisites are required before the integration: .. image:: ../figures/cak1614112389132.png :width: 800 - - - -For instructions on creating, testing and terminating a -**ptp-notification-demo**, see, :ref:`Create, Test, and Terminate |PTP| -Notification Demo `. - - - diff --git a/doc/source/security/kubernetes/configure-local-cli-access.rst b/doc/source/security/kubernetes/configure-local-cli-access.rst index adc17e4cb..5676ae5ce 100644 --- a/doc/source/security/kubernetes/configure-local-cli-access.rst +++ b/doc/source/security/kubernetes/configure-local-cli-access.rst @@ -39,47 +39,47 @@ required system maintenance, administration and troubleshooting tasks. the system-managed KUBECONFIG file /etc/kubernetes/admin.conf, which can be changed and overwritten by the system. -#. Copy /etc/kubernetes/admin.conf to a private file under - /home/sysadmin such as /home/sysadmin/.kube/config, and update - /home/sysadmin/.profile to have the environment variable - point to the private file. + #. Copy /etc/kubernetes/admin.conf to a private file under + /home/sysadmin such as /home/sysadmin/.kube/config, and update + /home/sysadmin/.profile to have the environment variable + point to the private file. - For example, the following commands set up a private KUBECONFIG file. - - .. code-block:: none - - # ssh sysadmin@ - Password: - % mkdir .kube - % cp /etc/kubernetes/admin.conf .kube/config - % echo "export KUBECONFIG=~/.kube/config" >> ~/.profile - % exit - - .. note:: - The command + For example, the following commands set up a private KUBECONFIG file. .. code-block:: none - echo "export KUBECONFIG=~/.kube/config" >> ~/.profile + # ssh sysadmin@ + Password: + % mkdir .kube + % cp /etc/kubernetes/admin.conf .kube/config + % echo "export KUBECONFIG=~/.kube/config" >> ~/.profile + % exit - shown above is specific to CentOS. Substitute the correct syntax for your operating system. The following alternative is for Ubuntu: + .. note:: + The command + + .. code-block:: none + + echo "export KUBECONFIG=~/.kube/config" >> ~/.profile + + shown above is specific to CentOS. Substitute the correct syntax for your operating system. The following alternative is for Ubuntu: + + .. code-block:: none + + echo "export KUBECONFIG=~/.kube/config" >> ~/.bashrc + + #. Confirm that the environment variable is set correctly + and that :command:`kubectl` commands are functioning properly. .. code-block:: none - echo "export KUBECONFIG=~/.kube/config" >> ~/.bashrc + # ssh sysadmin@ + Password: + % env | fgrep KUBE + KUBECONFIG=/home/sysadmin/.kube/config + % kubectl get pods -#. Confirm that the environment variable is set correctly - and that :command:`kubectl` commands are functioning properly. - - .. code-block:: none - - # ssh sysadmin@ - Password: - % env | fgrep KUBE - KUBECONFIG=/home/sysadmin/.kube/config - % kubectl get pods - -.. rubric:: |result| + .. rubric:: |result| You can now access all |prod| commands. @@ -99,13 +99,6 @@ For example: | 1 | controller-0 | controller | unlocked | enabled | available | +----+--------------+-------------+----------------+-------------+--------------+ -.. note:: - In the following examples, the prompt is shortened to: - - .. code-block:: none - - ~(keystone_admin)]$ - Use :command:`system help` for a full list of :command:`system` subcommands. **fm commands** @@ -144,7 +137,16 @@ For example: NAME READY STATUS RESTARTS AGE dashboard-kubernetes-dashboard-7749d97f95-bzp5w 1/1 Running 0 3d18h -.. note:: - Use the remote Windows Active Directory server for authentication of - local :command:`kubectl` commands. +**Helm commands** +Helm commands are executed with the :command:`helm` command + +For example: + +.. code-block:: none + + % helm repo add bitnami https://charts.bitnami.com/bitnami + % helm repo update + % helm repo list + % helm search repo + % helm install wordpress bitnami/wordpress diff --git a/doc/source/security/kubernetes/configure-remote-cli-access.rst b/doc/source/security/kubernetes/configure-remote-cli-access.rst index d1d2ae512..293d29f66 100644 --- a/doc/source/security/kubernetes/configure-remote-cli-access.rst +++ b/doc/source/security/kubernetes/configure-remote-cli-access.rst @@ -42,5 +42,5 @@ either of the above two methods. :ref:`Install Kubectl and Helm Clients Directly on a Host ` - :ref:`Configure Remote Helm Client for Non-Admin Users + :ref:`Configure Remote Helm v2 Client ` \ No newline at end of file diff --git a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst index 2c6fa1ef2..7685374f2 100644 --- a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst +++ b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst @@ -2,44 +2,141 @@ .. oiz1581955060428 .. _configure-remote-helm-client-for-non-admin-users: -================================================ -Configure Remote Helm Client for Non-Admin Users -================================================ +=============================== +Configure Remote Helm v2 Client +=============================== -For non-admin users \(i.e. users without access to the default Tiller -server running in kube-system namespace\), you must create a Tiller server -for this specific user in a namespace that they have access to. +Helm v3 is recommended for users to install and manage their +containerized applications. However, Helm v2 may be required, for example, if +the containerized application supports only a Helm v2 helm chart. .. rubric:: |context| -By default, helm communicates with the default Tiller server in the -kube-system namespace. This is not accessible by non-admin users. - -For non-admin users use of the helm client, you must create your own Tiller -server, in a namespace that you have access to, with the required |RBAC| +Helm v2 is only supported remotely. Also, it is only supported with kubectl and +Helm v2 clients configured directly on the remote host workstation. In +addition to installing the Helm v2 clients, users must also create their own +Tiller server, in a namespace that the user has access, with the required |RBAC| capabilities and optionally |TLS| protection. -To create a Tiller server with |RBAC| permissions within the default -namespace, complete the following steps on the controller: Except where -indicated, these commands can be run by the non-admin user, locally or -remotely. - -.. note:: - If you are using container-backed helm CLIs and clients \(method 1\), - ensure you change directories to <$HOME>/remote\_cli\_wd +Complete the following steps to configure Helm v2 for managing containerized +applications with a Helm v2 helm chart. .. rubric:: |proc| - .. _configure-remote-helm-client-for-non-admin-users-steps-isx-dsd-tkb: -#. Set the namespace. +#. On the controller, create an admin-user service account if this is not + already available. + + #. Create the **admin-user** service account in **kube-system** + namespace and bind the **cluster-admin** ClusterRoleBinding to this user. + + .. code-block:: none + + % cat < admin-login.yaml + apiVersion: v1 + kind: ServiceAccount + metadata: + name: admin-user + namespace: kube-system + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRoleBinding + metadata: + name: admin-user + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin + subjects: + - kind: ServiceAccount + name: admin-user + namespace: kube-system + EOF + % kubectl apply -f admin-login.yaml + + #. Retrieve the secret token. + + .. code-block:: none + + % kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') + + +#. On the workstation, if it is not available, install the :command:`kubectl` client on an Ubuntu + host by taking the following actions on the remote Ubuntu system. + + #. Install the :command:`kubectl` client CLI. + + .. code-block:: none + + % sudo apt-get update + % sudo apt-get install -y apt-transport-https + % curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ + sudo apt-key add + % echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | \ + sudo tee -a /etc/apt/sources.list.d/kubernetes.list + % sudo apt-get update + % sudo apt-get install -y kubectl + + #. Set up the local configuration and context. + + .. note:: + In order for your remote host to trust the certificate used by + the |prod-long| K8S API, you must ensure that the + **k8s\_root\_ca\_cert** specified at install time is a trusted + CA certificate by your host. Follow the instructions for adding + a trusted CA certificate for the operating system distribution + of your particular host. + + If you did not specify a **k8s\_root\_ca\_cert** at install + time, then specify –insecure-skip-tls-verify, as shown below. + + .. code-block:: none + + % kubectl config set-cluster mycluster --server=https://:6443 \ + --insecure-skip-tls-verify + % kubectl config set-credentials admin-user@mycluster --token=$TOKEN_DATA + % kubectl config set-context admin-user@mycluster --cluster=mycluster \ + --user admin-user@mycluster --namespace=default + % kubectl config use-context admin-user@mycluster + + <$TOKEN\_DATA> is the token retrieved in step 1. + + #. Test remote :command:`kubectl` access. + + .. code-block:: none + + % kubectl get nodes -o wide + NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE ... + controller-0 Ready master 15h v1.12.3 192.168.204.3 CentOS L ... + controller-1 Ready master 129m v1.12.3 192.168.204.4 CentOS L ... + worker-0 Ready 99m v1.12.3 192.168.204.201 CentOS L ... + worker-1 Ready 99m v1.12.3 192.168.204.202 CentOS L ... + % + +#. Install the Helm v2 client on remote workstation. + + .. code-block:: none + + % wget https://get.helm.sh/helm-v2.13.1-linux-amd64.tar.gz + % tar xvf helm-v2.13.1-linux-amd64.tar.gz + % sudo cp linux-amd64/helm /usr/local/bin + + Verify that :command:`helm` is installed correctly. + + .. code-block:: none + + % helm version + Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"} + Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"} + +#. Set the namespace for which you want Helm v2 access to. .. code-block:: none ~(keystone_admin)]$ NAMESPACE=default -#. Set up accounts, roles and bindings. +#. Set up accounts, roles and bindings for Tiller (Helm v2 cluster access). #. Execute the following commands. @@ -94,7 +191,8 @@ remotely. --clusterrole tiller --serviceaccount ${NAMESPACE}:tiller -#. Initialize the Helm account. +#. Initialize Helm v2 access with :command:`helm init` command to start Tiller in the + specified NAMESPACE with the specified RBAC credentials. .. code-block:: none @@ -133,7 +231,7 @@ remotely. .. rubric:: |result| -You can now use the private Tiller server remotely or locally by specifying +You can now use the private Tiller server remotely by specifying the ``--tiller-namespace`` default option on all helm CLI commands. For example: @@ -142,19 +240,6 @@ example: helm version --tiller-namespace default helm install --name wordpress stable/wordpress --tiller-namespace default -.. note:: - If you are using container-backed helm CLI and Client \(method 1\), then - you change directory to <$HOME>/remote\_cli\_wd and include the following - option on all helm commands: - - .. code-block:: none - - —home "./.helm" - -.. note:: - Use the remote Windows Active Directory server for authentication of - remote :command:`kubectl` commands. - .. seealso:: :ref:`Configure Container-backed Remote CLIs and Clients diff --git a/doc/source/security/kubernetes/index.rst b/doc/source/security/kubernetes/index.rst index 121463ffc..628b5ff43 100644 --- a/doc/source/security/kubernetes/index.rst +++ b/doc/source/security/kubernetes/index.rst @@ -75,7 +75,6 @@ Access the System install-the-kubernetes-dashboard security-rest-api-access connect-to-container-registries-through-a-firewall-or-proxy - using-container-backed-remote-clis-and-clients *************************** Manage Non-Admin Type Users diff --git a/doc/source/security/kubernetes/remote-access-index.rst b/doc/source/security/kubernetes/remote-access-index.rst index df231ba7a..23388e904 100644 --- a/doc/source/security/kubernetes/remote-access-index.rst +++ b/doc/source/security/kubernetes/remote-access-index.rst @@ -7,5 +7,6 @@ Remote CLI Access configure-remote-cli-access security-configure-container-backed-remote-clis-and-clients + using-container-backed-remote-clis-and-clients security-install-kubectl-and-helm-clients-directly-on-a-host configure-remote-helm-client-for-non-admin-users \ No newline at end of file diff --git a/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst b/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst index 3e81f8bcb..7b2a8dbd4 100644 --- a/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst +++ b/doc/source/security/kubernetes/security-configure-container-backed-remote-clis-and-clients.rst @@ -52,6 +52,8 @@ The following procedure shows how to configure the Container-backed Remote CLIs and Clients for an admin user with cluster-admin clusterrole. If using a non-admin user such as one with privileges only within a private namespace, additional configuration is required in order to use :command:`helm`. +The following procedure shows how to configure the Container-backed Remote +CLIs and Clients for an admin user with cluster-admin clusterrole. .. rubric:: |proc| @@ -150,7 +152,12 @@ additional configuration is required in order to use :command:`helm`. OAM_IP="[${OAM_IP}]" fi + #. Change the permission to be readable. + .. code-block:: none + + ~(keystone_admin)]$ sudo chown sysadmin:sys_protected ${OUTPUT_FILE} + sudo chmod 644 ${OUTPUT_FILE} #. Generate the admin-kubeconfig file. @@ -196,11 +203,6 @@ additional configuration is required in order to use :command:`helm`. convenience, this example assumes that it is copied to the location of the extracted tarball. - .. note:: - Ensure that the admin-kubeconfig file has 666 permissions after copying - the file to the remote workstation, otherwise, use the following - command to change permissions, :command:`chmod 666 temp\_kubeconfig`. - #. On the remote workstation, configure remote CLI/client access. This step will also generate a remote CLI/client RC file. @@ -234,8 +236,9 @@ additional configuration is required in order to use :command:`helm`. rmclients:stx.4.0-v1.3.0 If you specify repositories that require authentication, as shown - above, you must first remember to perform a :command:`docker login` to - that repository before using remote |CLIs| for the first time. + above, you must first perform a :command:`docker login` to that + repository before using remote |CLIs|. WRS |AWS| ECR credentials or a + |CA| certificate is required. The options for configure\_client.sh are: @@ -329,6 +332,6 @@ See :ref:`Using Container-backed Remote CLIs and Clients ` - :ref:`Configure Remote Helm Client for Non-Admin Users + :ref:`Configure Remote Helm v2 Client ` diff --git a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst index 3f5eeaf6f..0eb5e0939 100644 --- a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst +++ b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst @@ -61,13 +61,14 @@ configuration is required in order to use :command:`helm`. .. code-block:: none - % kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') + ~(keystone_admin)]$ TOKEN_DATA=$(kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') | grep "token:" | awk '{print $2}') -#. On the workstation, install the :command:`kubectl` client on an Ubuntu - host by taking the following actions on the remote Ubuntu system. +#. On a remote workstation, install the :command:`kubectl` client. Go to the + following link: `https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ + `__. - #. Install the :command:`kubectl` client CLI. + #. Install the :command:`kubectl` client CLI (for example, an Ubuntu host). .. code-block:: none @@ -93,9 +94,15 @@ configuration is required in order to use :command:`helm`. If you did not specify a **k8s\_root\_ca\_cert** at install time, then specify –insecure-skip-tls-verify, as shown below. + The following example configures the default ~/.kube/config. See the + following reference: + `https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/ + `__. + You need to obtain a floating |OAM| IP. + .. code-block:: none - % kubectl config set-cluster mycluster --server=https://:6443 \ + % kubectl config set-cluster mycluster --server=https://${OAM_IP}:6443 \ --insecure-skip-tls-verify % kubectl config set-credentials admin-user@mycluster --token=$TOKEN_DATA % kubectl config set-context admin-user@mycluster --cluster=mycluster \ @@ -119,12 +126,15 @@ configuration is required in order to use :command:`helm`. #. On the workstation, install the :command:`helm` client on an Ubuntu host by taking the following actions on the remote Ubuntu system. - #. Install :command:`helm`. + #. Install :command:`helm`. See the following reference: + `https://helm.sh/docs/intro/install/ + `__. Helm accesses the Kubernetes + cluster as configured in the previous step, using the default ~/.kube/config. .. code-block:: none - % wget https://get.helm.sh/helm-v2.13.1-linux-amd64.tar.gz - % tar xvf helm-v2.13.1-linux-amd64.tar.gz + % wget https://get.helm.sh/helm-v3.2.1-linux-amd64.tar.gz + % tar xvf helm-v3.2.1-linux-amd64.tar.gz % sudo cp linux-amd64/helm /usr/local/bin @@ -133,8 +143,17 @@ configuration is required in order to use :command:`helm`. .. code-block:: none % helm version - Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"} - Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"} + version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} + + #. Run the following commands: + + .. code-block:: none + + % helm repo add bitnami https://charts.bitnami.com/bitnami + % helm repo update + % helm repo list + % helm search repo + % helm install wordpress bitnami/wordpress .. seealso:: @@ -144,6 +163,6 @@ configuration is required in order to use :command:`helm`. :ref:`Using Container-backed Remote CLIs and Clients ` - :ref:`Configure Remote Helm Client for Non-Admin Users + :ref:`Configure Remote Helm v2 Client ` diff --git a/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst b/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst index efa13daeb..880245655 100644 --- a/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst +++ b/doc/source/security/kubernetes/using-container-backed-remote-clis-and-clients.rst @@ -16,8 +16,9 @@ variables and aliases for the remote |CLI| commands. - Consider adding the following command to your .login or shell rc file, such that your shells will automatically be initialized with the environment - variables and aliases for the remote |CLI| commands. Otherwise, execute it - before proceeding: + variables and aliases for the remote |CLI| commands. + + Otherwise, execute it before proceeding: .. code-block:: none @@ -44,7 +45,6 @@ variables and aliases for the remote |CLI| commands. .. code-block:: none - Please enter your OpenStack Password for project admin as user admin: root@myclient:/home/user/remote_cli_wd# system host-list +----+--------------+-------------+----------------+-------------+--------------+ | id | hostname | personality | administrative | operational | availability | @@ -83,8 +83,8 @@ variables and aliases for the remote |CLI| commands. In most cases, the remote |CLI| will detect and handle these commands correctly. If you encounter cases that are not handled correctly, you - can force-enable or disable the shell options using the - or variables before the command. + can force-enable or disable the shell options using the + or variables before the command. For example: @@ -110,37 +110,26 @@ variables and aliases for the remote |CLI| commands. root@myclient:/home/user/remote_cli_wd# kubectl -n kube-system delete -f test.yml pod/test-pod deleted -- Do the following to use helm. +- For Helm commands: + + .. code-block:: none + + % cd $HOME/remote_cli_wd .. note:: - For non-admin users, additional configuration is required first as - discussed in :ref:`Configuring Remote Helm Client for Non-Admin Users - `. - - .. note:: - When using helm, any command that requires access to a helm repository - \(managed locally\) will require that you be in the + When using helm, any command that requires access to a helm + repository \(managed locally\) will require that you be in the $HOME/remote\_cli\_wd directory and use the --home ./.helm option. + For the host local installation, it requires the users $HOME and + ends up in $HOME/.config and $HOME/.cache/helm. + .. code-block:: none - #. Do the initial setup of the helm client. - - .. note:: - This command assumes you are using Helm v2. - - .. code-block:: none - - % cd $HOME/remote_cli_wd - % helm init --client-only --home "./.helm" - - #. Run a helm command. - - .. code-block:: none - - % cd $HOME/remote_cli_wd - % helm list - % helm install --name wordpress stable/wordpress --home "./.helm" - + % helm --home ./.helm repo add bitnami https://charts.bitnami.com/bitnami + % helm --home ./.helm repo update + % helm --home ./.helm repo list + % helm --home ./.helm search repo + % helm --home ./.helm install wordpress bitnami/wordpress **Related information** @@ -153,6 +142,6 @@ variables and aliases for the remote |CLI| commands. :ref:`Installing Kubectl and Helm Clients Directly on a Host ` - :ref:`Configuring Remote Helm Client for Non-Admin Users + :ref:`Configure Remote Helm v2 Client ` diff --git a/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-helm-package-manager.rst b/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-helm-package-manager.rst index bc6ca8de8..5225b727a 100644 --- a/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-helm-package-manager.rst +++ b/doc/source/usertasks/kubernetes/kubernetes-user-tutorials-helm-package-manager.rst @@ -6,8 +6,8 @@ Helm Package Manager ==================== -|prod-long| supports Helm with Tiller, the Kubernetes package manager that can -be used to manage the lifecycle of applications within the Kubernetes cluster. +|prod-long| supports Helm v3 package manager for Kubernetes that can +be used to securely manage the lifecycle of applications within the Kubernetes cluster. .. rubric:: |context| @@ -17,26 +17,12 @@ your Kubernetes applications using Helm charts. Helm charts are defined with a default set of values that describe the behavior of the service installed within the Kubernetes cluster. -Upon system installation, the official curated helm chart repository is added -to the local helm repo list, in addition, a number of local repositories -\(containing optional |prod-long| packages\) are created and added to the helm -repo list. For more information, see `https://github.com/helm/charts -`__. - -Use the following command to list the helm repositories: - -.. code-block:: none - - ~(keystone_admin)]$ helm repo list - NAME URL - stable https://kubernetes-charts.storage.googleapis.com - local http://127.0.0.1:8879/charts - starlingx http://127.0.0.1:8080/helm_charts/starlingx - stx-platform http://127.0.0.1:8080/helm_charts/stx-platform +|prod| recommends a non-admin end-user to install a Helm v3 client on a remote +workstation to enable management of their Kubernetes applications. For more information on Helm, see the documentation at `https://helm.sh/docs/ `__. -**Tiller** is a component of Helm. Tiller interacts directly with the -Kubernetes API server to install, upgrade, query, and remove Kubernetes -resources. +For more information on how to configure and use Helm both locally and remotely, see :ref:`Configure Local CLI Access `, +and :ref:`Configure Remote CLI Access `. +