#kubernetes labels vs selectors

[codeonedigest]

Kubernetes Labels and Selectors Tutorial for Beginners

Hi, a new #video on #kubernetes #labels and #selectors is published on #codeonedigest #youtube channel. Learn kubernetes #labelsandselectors #apiserver #kubectl #docker #proxyserver #programming #coding with #codeonedigest #kuberneteslabelsandselectors

Kubernetes Labels are key-value pairs which are attached to pods, replication controller and services. They are used as identifying attributes for objects such as pods and replication controller. They can be added to an object at creation time and can be added or modified at the run time. Kubernetes selectors allows us to select Kubernetes resources based on the value of labels and resource…

[inthetechpit]

Kubernetes ReplicaSet example on Mac using VS Code

Kubernetes ReplicaSet example on Mac using VS Code

A ReplicaSet helps load balance and scale our Application up or down when the demand for it changes. It makes sure the desired number of pods are always running for high availability. I’m using VS Code on Mac to create the below yaml file. Create the following yaml file: apiVersion: apps/v1 kind: ReplicaSet metadata: name: myapp-replicaset labels: app: myapp spec: selector: matchLabels: app:…

[datamattsson]

Using Traefik for simple Kubernetes Ingress

I’m a huge fan how Routes work in OpenShift. It’s just there when the platform is deployed and ready to use. All it needs externally is a wildcard DNS entry (CNAME that points to the compute nodes) to start serving HTTP/HTTPS traffic. Routes is nothing but a type of Ingress that is specific to OpenShift (Red Hat people will probably come after me for stating this, please excuse my ignorance). I wanted to figure out how to get this exact same behavior for a demo I did on both OpenShift and vanilla Kubernetes without too much hassle.

Swiss Army knife Traefik

I’ve dabbled a bit in the past with Traefik on Docker Swarm. It turns out it’s just as intuitive to setup and use on Kubernetes. It also meets my key objective, look and feel like Routes to reuse declarations between environments. Traefik is incredibly flexible and you can make it perform application routing like no other, but for my use case, I simply “unbox” it and it just works.

The full documentation on how to deploy this on Kubernetes is available in the Traefik User Guide for Kubernetes. There are multiple ways to deploy to Kubernetes but for my use case, the DaemonSet worked best. I’m not paying attention to HTTPS at this time and I suspect that is one of the areas where using OpenShift Routes vs Traefik will differ.

Deploy

I’m not going to be fuzzy and force a different deployment than the one from the official repos. So, go ahead:

kubectl apply -f https://raw.githubusercontent.com/containous/traefik/v1.7/examples/k8s/traefik-rbac.yaml kubectl create -f https://raw.githubusercontent.com/containous/traefik/v1.7/examples/k8s/traefik-ds.yaml

An optional step is to deploy the Service and Ingress for the Traefik UI. This YAML require modification depending on your wildcard DNS entry.

--- apiVersion: v1 kind: Service metadata: name: traefik-web-ui namespace: kube-system spec: selector: k8s-app: traefik-ingress-lb ports: - name: web port: 80 targetPort: 8080 --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: traefik-web-ui namespace: kube-system spec: rules: - host: traefik-ui.dev.datamattsson.io http: paths: - path: / backend: serviceName: traefik-web-ui servicePort: web

Note the .spec.rules.0.host value, which is grabbing a name from my *.dev.datamattsson.io DNS entry.

The UI is now accessible on http://traefik-ui.<your domain>:8080 and should look similar to this:

Since my test systems are sitting fairly dormant in my labs, I don't bother securing access to the UI. If you're on a publicly accessible network, it's advised to secure the UI.

The UI Ingress can be secured like any other Ingress with Traefik as outlined in the official docs.

First, create a password file with the htpasswd command (the htpasswd command you may find lurking in the httpd-tools package on CentOS/RHEL, other distros may vary).

htpasswd -c ./passwd admin

Answer the prompts for a new password.

Create a Kubernetes secret from the passwd file.

kubectl create secret generic traefik-ui-secret --from-file passwd --namespace=kube-system

Next, you need to patch your Ingress created in the previous step with these annotations:

metadata: annotations: kubernetes.io/ingress.class: traefik traefik.ingress.kubernetes.io/auth-type: "basic" traefik.ingress.kubernetes.io/auth-secret: "traefik-ui-secret"

Save this to a file named mypatch.yaml and run:

kubectl -n kube-system patch ingress traefik-web-ui --patch "$(cat mypatch.yaml)"

Hit refresh on the UI and you'll be prompted by your web browser to input admin as user and the password you gave at the prompts.

Hello World

Now we’re all set. Another thing you could do is check that the Traefik is responding by curl’ing a name:

curl http://foobar.dev.datamattsson.io/ 404 page not found

The example application I was using in my demos was WordPress. So, for my Service and Ingress, I would deploy the following:

--- apiVersion: v1 kind: Service metadata: labels: app: wordpress name: wordpress spec: type: LoadBalancer ports: - name: wordpress port: 8080 targetPort: 80 protocol: TCP selector: app: wordpress --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: wordpress spec: rules: - host: wp.dev.datamattsson.io http: paths: - path: / backend: serviceName: wordpress servicePort: wordpress

If I would diff the Kubernetes variant versus the OpenShift variant, this is what it would look like:

13c13 targetPort: 8080 24c24 - host: wp.apps.openshift.datamattsson.io

The difference in port numbers is that the OpenShift doesn’t allow Pods to bind ports below 1024 with the default restricted SecurityContextConstraints.

I have not deployed my WordPress app but you should be able to observe that Traefik grabbed the Ingress:

curl http://wp.dev.datamattsson.io/ Service Unavailable

Need might arise to do the HTTPS version of this in the future. Until then, Happy Routing!