Steps to run an application on Windows using Docker and Minikube: 

Overview: 

There are only two steps: 

1. Prepare an external insecure docker registry  

2. Start the minikube with this external insecure docker registry 

The insecure term is used only for http versus https. It was required because docker and minikube on windows work together by taking an –insecure-registry as a start-up parameter. This is not the case on Linux where we can do without this parameter and have the minikube host its own docker registry. On windows, we install Docker toolbox and Minikube separately. This gives us two virtual machines by name ‘default’ for docker and ‘minikube’ for the Kubernetes cluster. Both are linux environments and we can one to install DESDP in another. 

Please allow your insecure registry sufficient disk space. The default size is about 18GB and this is not sufficient. You need at least 30 GB for a plethora of images. Docker toolbox is preferred over other software packages for installing Docker on Windows. 

Please allow your minikube to start with at least 2 cpu and 8GB memory. You need this much for the flink and pravega clusters in the deployment. 

Steps explained: 

1. Preparing and using an external insecure docker registry: 

1. You can use any host for your insecure registry including ubuntu vms. I used vm1.xyz.com. Run the following commands: 

1. Pull the image 

docker pull registry 

2. # start a container with the pulled image 

docker run --name regdock -p 5000:5000 -d registry 

3. # see regdock container created 

docker ps 

4. # go to docker configuration 

cd /etc/docker 

5. # specify the daemon.json config 

echo ‘{"insecure-registries":["vm1.xyz.com:5000"]}’ > /etc/daemon.json 

6. # test with pushing an image: 

docker push vm1.xyz.com:5000/hello-world:latest 

2. If you want a secure registry and use the docker within the minikube, you could: 

1. minikube kubectl create secret tls registry-docker-registry-tls --cert=..\minikube.crt --key=..\minikube.key 

secret/registry-docker-registry-tls created 

2. helm install stable/docker-registry --name registry --set tlsSecretName=registry-docker-registry-tls --set persistence.enabled=true --set service.type=NodePort --set service.nodePort=31001  

NAME:   registry 

LAST DEPLOYED: Fri Apr  3 17:15:29 2020 

NAMESPACE: default 

STATUS: DEPLOYED 

RESOURCES: 

==> v1/ConfigMap 

NAME                             DATA  AGE 

registry-docker-registry-config  1     0s 

==> v1/Deployment 

NAME                      READY  UP-TO-DATE  AVAILABLE  AGE 

registry-docker-registry  0/1    1           0          0s 

==> v1/PersistentVolumeClaim 

NAME                      STATUS  VOLUME                                    CAPACITY  ACCESS MODES  STORAGECLASS  AGE 

registry-docker-registry  Bound   pvc-cad1d7c1-e6d3-4258-95bd-4031da239377  10Gi      RWO           standard      0s 

==> v1/Pod(related) 

NAME                                       READY  STATUS             RESTARTS  AGE 

registry-docker-registry-7f798b64bd-s5j89  0/1    ContainerCreating  0         0s 

==> v1/Secret 

NAME                             TYPE    DATA  AGE 

registry-docker-registry-secret  Opaque  1     0s 

==> v1/Service 

NAME                      TYPE      CLUSTER-IP      EXTERNAL-IP  PORT(S)         AGE 

registry-docker-registry  NodePort  10.106.117.104  <none>       5000:31001/TCP  0s 

3. # get the port for this registry service: 

kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services registry-docker-registry 

4. # get the ip address for this registry service 

kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}" 

5. # Always remember to import your certificate to your local machine and reboot the windows host 

3. #Test the insecure registry 

curl -i http://vm1.xyz.com:5000 

HTTP/1.1 200 OK 

Cache-Control: no-cache 

Date: Sat, 04 Apr 2020 00:28:54 GMT 

Content-Length: 0 

4. # 

2. Start the minikube with 

minikube start --vm-driver=virtualbox --dns-domain xyz.com --insecure-registry vm1.xyz.com --host-dns-resolver=true --disk-size=50000mb --cpus=2 --memory=8000mb --dns-domain='xyz.com' --kubernetes-version=v1.15.6 --alsologtostderr -v=8 --wait=true 

If we need to use the windows host to connect to docker, we will have to specify the environment variables as follows: 

SET DOCKER_TLS_VERIFY=<empty|1> 

SET DOCKER_CERT_PATH=~/.docker 

SET DOCKER_HOST=tcp://<ip>:<port> 

SET DOCKER_MACHINE=<default|minikube> 

We were discussing custom resources for user data.
The size and the separation of concerns between the kubectl resource and its associated data does not stop with the external service and the kube-api server. The binding between the resource and the external service is managed with the help of a service catalog which lets services to be hosted outside the cluster. It adheres to OSBA api. It allows services to be independent and scaleable. It allows services to define their own resources.
The disadvantages of defining a resource for provisioning externally is that it has no relationship with other Kubernetes resources and the catalog is not able to enforce a sync between the resource and its provisioner’s last known state. The infrastructure finds the resource opaque and interpretable only by the external provisioner which may or may not be the source of truth.
The service broker then leads to a model where the resource has to become more composable from finer resources and the composition becomes the form of organization.  This could lead to a hybrid model where a larger custom resource is composed of smaller self-contained resources.
The catalog keeps instance and binding at a cluster wide or namespace scope. These are helpful for keeping track of accounts and roles to interact with the external service providers. The resource itself does not persist in the catalog until recently when etcd was made part of it.  Since the resource declarations and the logic to reconcile it rests outside the catalog, it is easy for them to implement self contained resources or those with referenced data bindings.
The user data has so far been represented by a K8s resource. The resource is only a representation for data to be fetched from service providers, either internal or external to the cluster. The resource can also have metadata that can help with its versioning, point of origin and signatures.
The use of metadata to improve the information on the resource without having to introspect the resource helps in making decisions about the resources and for visibility between source and destination of transfer.

Unlike traditional application frameworks, Kubernetes has a special meaning for service accounts. While service accounts continue to be different from user accounts where the former represents applications and the latter represents users, Kubernetes persists service accounts while delegating the same for user accounts to identity providers. The notion behind not persisting user accounts is that Kubernetes does not authenticate users, it validates assertions. Each request must assert an identity to Kubernetes. There is no web interface, login or session associated with this identity. Kubernetes honors requests and every action is specified with the help of an API request. Each request is unique, distinct and self-contained for authentication and authorization purposes. Identity is merely an assertion in these requests.
Service accounts are meant for interactions between applications and Kubernetes resources. A service account is injected by the admission controller at the time of resource creation if one is not provided already. This is the default service account and bears the name as such. A service account should never be mixed with user account otherwise they suffer many drawbacks. It should only be authorized with role-based access control otherwise any other scheme will encounter numerous items to audit. It should never be leaked, otherwise it can be abused indefinitely.
This last item requires a rotation of service accounts so that the misuse of a service account is limited to its discovery or a the issue of a new account. A service account is represented by a toke gold mounted at the location /var/run/secrets/kubernetes.io/serviceaccount in a Kubernetes pod. This can be injected and made to work with the same resources as earlier with the help of wrapping one secret into another
The persistence of service accounts and their usage as a secret makes it valuable to an autonomous secret management system that can keep track of secrets and rotate them as necessary. The external key manager that manages keys and certificates was built for a similar purpose where the secret was a key certificate. That system can work well for Kubernetes since the framework poses no limitation to injection or rotation.
The automation of periodic and on-demand rotation improves security and convenience for all Kubernetes usage.