Kubernetes Up & Running: Chapter 2

Page 16

1. make sure you’ve cloned the git repo mentioned earlier in the chapter

2. once in the repo, run:

make build

to build the application.

3. create this Dockerfile (not the one mentioned in the book)

MAINTAINER is deprecated. Use a LABEL instead: https://github.com/kubernetes-up-and-running/kuard/issues/7

And the  COPY path in the book is incorrect.

and run

docker build -t kuard-amd64:1 .

to build the Dockerfile.

Here we’ve got a repo name of kuard-amd64 and a tag of 1.

https://docs.docker.com/engine/reference/commandline/build/#tag-an-image–t

4. Check the repo using

docker images

Note: a registry is a collection of repositories, and a repository is a collection of images

https://docs.docker.com/get-started/part2/#recap-and-cheat-sheet-optional

 

Page 19

docker tag kuard-amd64:1 gcr.io/kuar-demo/kuard-amd64:1

According to https://docs.docker.com/get-started/part2/#tag-the-image

the tag command is:

docker tag image username/repository:tag

so image is kuard-amd64:1

but what’s the username?

Is it gcr.io ?

Or gcr.io/kuar-demo?

The answer is that Docker’s docs here:

https://docs.docker.com/get-started/part2/#tag-the-image

are incorrect. You don’t need a username or repository. It’s just a label. E.g. see https://docs.docker.com/engine/reference/commandline/tag/

Correct would be:

docker tag image <any label you want>:tag

BUT for the purposes of pushing to a repository that label DOES need to be of a specific format. i.e. username/image_name.

https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker

Shame they didn’t explain that in more detail.

 

And the next line is misleading too.

docker push gcr.io/kuar-demo/kguard-amd64:1

This creates the impression that you’re pushing your image to a website (or registry) hosted at gcr.io.

It’s not.

It’s just the tag you created above. Having said that, I had to simplify the tag (from 2 slashes to 1 slash) to get it to work. E.g.

docker tag kuard-amd64:1 snowcrasheu/kuard-amd64:1

The reason for

denied: requested access to the resource is denied

is that (from https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker )

https://stackoverflow.com/questions/41984399/denied-requested-access-to-the-resource-is-denied-docker

 

To login with docker use:

docker login

or to use a specific username / password.

docker login -u <username> -p <password>

Better is --password-stdin however.

and push with:

docker push snowcrasheu/kuard-amd64:1

which you should then be able to see on Docker Hub. E.g.

https://hub.docker.com/r/snowcrasheu/kuard-amd64/

 

Notes:

How to change a repository name: 

https://stackoverflow.com/questions/25211198/docker-how-to-change-repository-name-or-rename-image/25214186#25214186

 

Kubernetes: Dummy Pod

So we can test kubectl let’s create a dummy pod.

Apply with:

kubectl apply -f pod.yaml

and test with:

kubectl get pods

 

I get:

 

The logs won’t show anything ‘cos it hasn’t started yet.

Let’s describe the pod.

k describe pod w-dummy-pod

Memory pressure.

Let’s give minikube more memory.

minikube config set memory 2048

then

and we can exec in with:

k exec -it w-dummy-pod bash

 

Let’s check we can cp a file in:

echo "test" > test.txt

Prove it doesn’t exist in the Pod by:

k exec -it w-dummy-pod bash

and ls

Then:

k cp test.txt w-dummy-pod:/testing.txt

and then exec in and ls.

 

 

 

 

 

 

Kubernetes: Service Accounts

A service account provides an identity for processes that run in a Pod.

 

e.g. if you access the cluster using kubectlyou’re authenticated by apiserver as a user account (e.g. admin).

Processes in containers also contact apiserver and are authenticated (e.g. if you don’t specify an account then it’s assigned default).

 

Check pod service account name via:

kubectl get pods/podname -o yaml

and see spec.serviceAccountName

 

List service accounts:

There doesn’t seem to be a way to view them via the Kubernetes Dashboard.

 

 

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

 

 

Service Meshes on Kubernetes: Istio, Linkerd, SuperGloo

Quick note: there’s a lot going on in the Service Mesh space for Kubernetes.

Istio (based on Envoy) is the elephant in the room with a ton of funding.

But there’s also Linkerd and SuperGloo.

And a recent announcement from AWS: AWS App Mesh.

 

Great summary of Istio:

Generally traffic is defined as north/south (into and out of the datacenter) or east/west (between servers in the datacenter).

Istio is for east/west traffic within your K8S cluster, designed to connect your services together by moving all the network traffic through the Envoy proxy. It is usually done by wrapping your deployments with an extra sidecar pod (automatically using K8S APIs) that intercepts all the networking to other services and pods. You would still use a load balancer or ingress to route external traffic into the cluster, although there are options like Heptio Contour that also use Envoy for this.

This provides a single data and control plane to centralize all network reliability, security, service discovery, and monitoring.

Note: Istio uses an extended version of the Envoy proxy: https://istio.io/docs/concepts/what-is-istio/#envoy
Istio provides:
  • Dynamic service discovery
  • Load balancing
  • TLS termination
  • HTTP/2 and gRPC proxies
  • Circuit breakers
  • Health checks
  • Staged rollouts with %-based traffic split
  • Fault injection
  • Rich metrics
And an interesting post about Service Meshes: