This is an easy way to access any of the pod services or pods from an external network.   Below are instructions on how to setup a SOCK5 proxy server and then how to configure Firefox running on a desktop to use the proxy server.  

The SOCK5 proxy server app is the ssh “Dynamic port forwarding” feature.  To enable it, a ssh session must be created with a pod using the ‘-D’ option.   The below instructions where tested in ONAP Amsterdam and use the portal-vnc pod. 

First connect to your portal-vnc  pod.

kubectl  exec -it  $(kubectl get pod  -lapp=portal-vnc -o jsonpath="{}")  bash

On the portal-vnc pod Install openssh-server and just use the factory settings

apt update
apt install openssh-server
service ssh start

On the portal-vnc pod, copy over a public ssh key.  For details on ssh key pair see

mkdir /root/.ssh
cat >> /root/.ssh/authorized_keys << EOF
put the public key here

To be able to create a ssh session from a client external to kubernetes,  a NodePort must be created for the session to pass through.  So on a box running the kubectl client ,  Create the following file and fill in the NAMESPACE and NODE-PORT.  

cat > portal-vnc-service.yaml <<EOF
apiVersion: v1
kind: Service
  name: portal-vnc-ssh
    app: portal-vnc-ssh
  namespace: NAMESPACE
  - name: portal-3
    nodePort: NODE-PORT
    port: 22
    protocol: TCP
    targetPort: 22
    app: portal-vnc
  type: NodePort

Create the Service in kubernetes

kubectl create -f ./portal-vnc-service.yaml

Start the sock 5 proxy server by opening a ssh session to the portal-vnc with Dynamic port forwarding enabled (-D).

On the host where the ssh private key resides,  executed the following command with the appropriate values.  The address of the proxy server will be  'socks5://localhost:PROXY-PORT' where localhost is where the ssh session is initiated from.  


This will  behave like a regular ssh session to portal-vnc.  

Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.9.78-rancher2 x86_64)

 * Documentation:
 * Management:
 * Support:
Last login: Mon Jun  4 16:56:31 2018 from

Closing the ssh session will close the proxy server too.   

Get the service IPs from portal-vnc from its the /etc/hosts file. 

cat /etc/hosts

Then add host ip mappings to the /etc/hosts  where the ssh session was initiated from. 

Don't just copy and paste the ip from this block post. The IPs are different on each ONAP deployment

sudo cat >> /etc/hosts << EOF

The proxy server can be configured with most web bowsers.  Here is an easy way to configure it in Firefox.  Just open Firefox preferences by typing 'about:preferences' in the address bar.  Then  search for proxy and click on the settings button that appears.  Finally enter the SOCKs details.  

The port 32003 in the following screen shot is the-D <PROXY-PORT> it the entered in the ssh command above.

Once configured just enter the ''   and then firefox will open up the ONAP portal.  Firefox will have access to any of the onap service IP.   Firefox must run on the same host where the ssh session was initiated from and were the /etc/hosts modified.  

For the Beijing release of ONAP on OOM, accessing the ONAP portal from the user's own environment (laptop etc.) was a frequently requested feature. 

So to achieve that, what we've decided on doing is to expose the portal application's port 8989 through a K8s LoadBalancer object.

This has some non-obvious implications in a clustered Kubernetes environment specifically where the K8s cluster nodes communicate with each other via a private network that isn't publicly accessible (i.e. Openstack VMs with private internal network).

Typically, to be able to access the K8s nodes publicly a public address is assigned.  In Openstack this is a floating IP address.

What happens when the portal-app chart is deployed is that a K8s service is created that instantiates a load balancer.  The LB chooses the private interface of one of the nodes (if happening in a multi-node K8S cluster deployment) as in the example below (i.e. in OpenStack, is the private IP of the specific K8s cluster node VM only). Then, to be able to access the portal on port 8989 from outside the OpenStack private network where the K8S cluster is connected to, the user needs to assign/get the specific floating IP address that corresponds to the private of the K8S Node VM where the Portal Service (as shown below) is deployed at.

kubectl -n onap get services|grep "portal-app"

portal-app                LoadBalancer                               8989:30215/TCP,8006:30213/TCP,8010:30214/TCP                                 1d        app=portal-app,release=dev

In this example, that public floating IP is which can be obtained through the horizon GUI or the Openstack CLI for your tenant (openstack server list) .  That IP is then used in your /etc/hosts to map the fixed DNS aliases required by the ONAP Portal as shown below.

Ensure you've disabled any proxy settings the browser you are using to access the portal and then simply access the familiar URL:

Other things we tried:

We went through using Kubernetes port forwarding but thought it a little clunky for the end user to have to use a script to open up port forwarding tunnels to each K8s pod that provides a portal application widget

We considered bringing back the VNC chart with a different image but there were many issues with resolution, lack of volume mount, /etc/hosts dynamic update, file upload that were a tall order to solve in time for the Beijing release.

I was banging my head against the wall trying to figure out why my K8s configmap was ignoring my file permission settings and injecting a read-only version into the container.  What was stranger was that it worked in my personal environment and not in the new one I set up for myself in the Windriver integration lab.

Well it turns out that there is a version difference between the 2 environments and this is exactly what the issue is.  In the 1.8.9 version of K8s, a fix went in that ensures all configmaps, secrets,

My personal environment is running K8s 1.8.5 and the Windriver environment K8s 1.8.10

Fix impact:

Secret, configMap, downwardAPI and projected volumes will be mounted as read-only volumes. Applications that attempt to write to these volumes will receive read-only filesystem errors. Previously, applications were allowed to make changes to these volumes, but those changes were reverted at an arbitrary interval by the system. Applications should be re-configured to write derived files to another location.

Here is the bug that led me to the discovery:

The commit:

And the changelog:

This was the ticket I was working at the time and I know that SO has a similar problem where the container is trying to modify/move a file/directory that is injected via configmap.

OOM-900 - Getting issue details... STATUS

Here is the code.  Note that setting the defaultMode: or mode: of a volume to something that is writeable isn't being honored anymore.

In OOM, many of us use Rancher to deploy Kubernetes to run ONAP.

Recently, I've had to update my lab environment from Rancher and Kubernetes 1.5 to rancher to v1.6 in order to upgrade the Kubernetes stack to v1.7.   I followed the steps on the Rancher website with 1 minor tweak: I used the rancher/server:stable image tag instead of latest

My rancher server container name was pensive_saha

docker stop pensive_saha
docker create --volumes-from pensive_saha --name rancher-data rancher/server:stable
docker pull rancher/server:stable
docker run -d --volumes-from rancher-data --restart=unless-stopped -p 8080:8080 rancher/server:stable

Once the server is back up, navigate to the rancher web page and navigate to Kubernetes > Infrastructure Stacks.

The "Up to date" button shown below, will say "Upgrade Available" for each stack. 

For each stack component, hit the button and select the most recent template from drop down, leave any input fields as their default and choose "Upgrade". 

Example: upgrading the healthcheck service stack

Rancher will do its thing to each K8s stack component and after it is done there will be a button that says "Complete upgrade".  Click that and the upgrade of the stack component will be complete.

You can now move on to the next component.

Once all stack status is "Green", the upgrade is complete.

To be deleted