Difference between revisions of "Kubernetes"

From UVOO Tech Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
You have two basic general flavors. Kubernetes and OKD (used to be OpenShift Origin). OKD uses HAProxy for routes while Kubernetes uses ingress and supports a bunch of different reverse proxy mechanisms including nginx. I think Kubernetes is developed enough over the last couple of years that it is a good option, maybe even better than openshift. Ubuntu Kubernetes is probably the best fit for now over kubeadm and other options.
 
You have two basic general flavors. Kubernetes and OKD (used to be OpenShift Origin). OKD uses HAProxy for routes while Kubernetes uses ingress and supports a bunch of different reverse proxy mechanisms including nginx. I think Kubernetes is developed enough over the last couple of years that it is a good option, maybe even better than openshift. Ubuntu Kubernetes is probably the best fit for now over kubeadm and other options.
 +
 +
# Best
 +
 +
https://kubernetes.io/docs/reference/kubectl/cheatsheet/
 +
 +
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
 +
 +
https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking
  
 
# Working
 
# Working
Line 8: Line 16:
  
 
# Install 1
 
# Install 1
 +
 +
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
  
 
https://medium.com/@zhimin.wen/gitlab-on-onprem-kubernetes-icp-3-1-b06dcd09df7c
 
https://medium.com/@zhimin.wen/gitlab-on-onprem-kubernetes-icp-3-1-b06dcd09df7c
Line 88: Line 98:
 
* https://kubedex.com/local-kubernetes/
 
* https://kubedex.com/local-kubernetes/
 
* https://cloudowski.com/articles/10-differences-between-openshift-and-kubernetes/
 
* https://cloudowski.com/articles/10-differences-between-openshift-and-kubernetes/
 +
 +
# Firewall
 +
 +
https://docs.oracle.com/cd/E52668_01/E88884/html/kube_admin_config_iptables.html
 +
```
 +
Kubernetes and iptables Rules
 +
Kubernetes uses iptables to handle many networking and port forwarding rules. Be careful of using services that may create conflicting iptables rules. You can check the rules by running iptables-save, which dumps the rule set to STDOUT.
 +
 +
If you intend to expose application services externally, by either using the NodePort or LoadBalancing service types, traffic forwarding must be enabled in your iptables rule set. If you find that you are unable to access a service from outside of the network used by the pod where your application is running, check that your iptables rule set does not contain a rule similar to the following:
 +
 +
:FORWARD DROP [0:0]
 +
If you have a rule to drop all forwarding traffic, you may need to run:
 +
 +
# iptables -P FORWARD ACCEPT
 +
If you are running iptables as a service instead of firewalld, you can save current iptables configuration so that it is persistent across reboots. To do this, run:
 +
 +
# iptables-save > /etc/sysconfig/iptables
 +
Note that you must have the iptables-services package installed for this to work. Oracle recommends using the default firewalld service as this provides a more consistent experience and allows you to make changes to the firewall configuration without flushing existing rules and reloading the firewall.
 +
 +
Nodes running applications that need to communicate directly between pods and that are IP aware, may require additional custom iptables configuration to bypass the default firewalld masquerading rules. For example, setting these two iptables rules on the nodes running a server application on IP address 192.0.2.15 and a client application on IP address 192.0.2.16 enables direct communication between them:
 +
 +
# iptables -t nat -I POST_public_allow -s 192.0.2.15/32 -d 192.0.2.16/32 -j RETURN
 +
# iptables -t nat -I POST_public_allow -s 192.0.2.16/32 -d 192.0.2.15/32 -j RETURN
 +
```

Latest revision as of 20:38, 29 July 2019

You have two basic general flavors. Kubernetes and OKD (used to be OpenShift Origin). OKD uses HAProxy for routes while Kubernetes uses ingress and supports a bunch of different reverse proxy mechanisms including nginx. I think Kubernetes is developed enough over the last couple of years that it is a good option, maybe even better than openshift. Ubuntu Kubernetes is probably the best fit for now over kubeadm and other options.

Best

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking

Working

https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/static-ip

https://docs.gitlab.com/ee/user/project/clusters/

Install 1

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

https://medium.com/@zhimin.wen/gitlab-on-onprem-kubernetes-icp-3-1-b06dcd09df7c

Getting Started with Calico as network control plane

https://docs.projectcalico.org/v3.8/getting-started/

Install

https://docs.projectcalico.org/v3.7/getting-started/kubernetes/

Note, if you want vxlan and easier in some ways but less scale/security try using flannel

Test it

https://docs.projectcalico.org/v3.7/security/simple-policy

Test simple container

Make sure dns and outbound connections are working

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

change example to busybox to ubuntu:bionic, debian:buster or whatever and rock an os.

Commands

kubeadm token create --print-join-command

kubectl port-forward service/my-service 48080:8080

Getting Started

https://kubernetes.io/docs/tasks/configure-pod-container/configure-volume-storage/

https://medium.com/@its_somrah/kubernetes-101-the-anatomy-b69831cf75be

https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/

https://medium.com/@anilkreddyr/kubernetes-with-flannel-understanding-the-networking-part-2-78b53e5364c7

https://stackoverflow.com/questions/44110876/kubernetes-service-external-ip-pending

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/reference/kubectl/cheatsheet/

Install On Ubuntu

Using kubeadm

https://linuxconfig.org/how-to-install-kubernetes-on-ubuntu-18-04-bionic-beaver-linux

MiniKube

https://dasunhegoda.com/kubernetes-running-locally-via-minikube/1204/

Microk8s

Kubernetes Charmed

https://kubernetes.io/docs/getting-started-guides/ubuntu/

https://docs.conjure-up.io/stable/en/user-manual#users-of-lxd

https://www.ubuntu.com/kubernetes

https://codefresh.io/kubernetes-tutorial/local-kubernetes-linux-minikube-vs-microk8s/

https://www.ubuntu.com/kubernetes/docs/quickstart

Comparisons

Firewall

https://docs.oracle.com/cd/E52668_01/E88884/html/kube_admin_config_iptables.html

Kubernetes and iptables Rules
Kubernetes uses iptables to handle many networking and port forwarding rules. Be careful of using services that may create conflicting iptables rules. You can check the rules by running iptables-save, which dumps the rule set to STDOUT.

If you intend to expose application services externally, by either using the NodePort or LoadBalancing service types, traffic forwarding must be enabled in your iptables rule set. If you find that you are unable to access a service from outside of the network used by the pod where your application is running, check that your iptables rule set does not contain a rule similar to the following:

:FORWARD DROP [0:0]
If you have a rule to drop all forwarding traffic, you may need to run:

# iptables -P FORWARD ACCEPT
If you are running iptables as a service instead of firewalld, you can save current iptables configuration so that it is persistent across reboots. To do this, run:

# iptables-save > /etc/sysconfig/iptables
Note that you must have the iptables-services package installed for this to work. Oracle recommends using the default firewalld service as this provides a more consistent experience and allows you to make changes to the firewall configuration without flushing existing rules and reloading the firewall.

Nodes running applications that need to communicate directly between pods and that are IP aware, may require additional custom iptables configuration to bypass the default firewalld masquerading rules. For example, setting these two iptables rules on the nodes running a server application on IP address 192.0.2.15 and a client application on IP address 192.0.2.16 enables direct communication between them:

# iptables -t nat -I POST_public_allow -s 192.0.2.15/32 -d 192.0.2.16/32 -j RETURN
# iptables -t nat -I POST_public_allow -s 192.0.2.16/32 -d 192.0.2.15/32 -j RETURN