Kubernetes Part 2 Lecture PDF

Official (Open) Kubernetes – Part 2 Official (Open) Namespace Used to partition a single Kubernetes cluster into multiple virtual clusters By default, it will be deployed to default namespace...

Official (Open) Kubernetes – Part 2 Official (Open) Namespace Used to partition a single Kubernetes cluster into multiple virtual clusters By default, it will be deployed to default namespace A good way of sharing a single cluster among different departments and environments. For example, a single cluster might have the following Namespaces. Dev Test QA Each one can have its own set of users and permissions. Official (Open) Inspect Namespaces Every Kubernetes cluster has a set of pre-created Namespaces Run the following command to list the namespaces in your cluster Official (Open) Create and manage Namespace Create a new Namespace, called “hydra” using kubectl command or using YAML Delete the ”hydra” Namespace Official (Open) Deploying to Namespaces Two ways to deploy objects to a specific Namespace Imperatively - add –n or --namespace flag to commands Declaratively Specifies Namespace in the YAML manifest file Official (Open) Pod Smallest unit in Kubernetes Abstraction over container my-app db Usually 1 application per pod IP IP Each pod gets its own IP address New IP address on re-creation Official (Open) Service & Ingress Permanent IP address Lifecycle of Pod and Service decoupled my-app db You specify the type of Service on creation ExternalService Service Service Service Internal Service is the default Internal http://node-ip:port http://service-ip:port Ingress http://192.168.1.1:port Official (Open) Service The Service fronts the Pods with a Service also load-balances traffic stable IP, DNS name and port. to Pods with the right labels With Service in place, the Pods can scale up and down, can fail and can be updated and rolled back. Service is observing the changes and updating its list of healthy Pods. Official (Open) Loosely coupled with Pods via labels and selectors Official (Open) Example on Service selecting on Pods Official (Open) ClusterIP default type of Kubernetes Service: ClusterIP ClusterIP is only accessible from inside the cluster E.g. creating a new Service called “magic-sandbox” will dynamically assign a stable ClusterIP Official (Open) NodePort Built on top of ClusterIP type Enable external access via a dedicated port on cluster node Official (Open) LoadBalancer Makes external access even easier Integrates with an internet-facing load-balancer Can access using public IP address Can even register friendly DNS names Official (Open) Ingress Limitations of NodePort: Requires knowledge of node names, only work on high port numbers (30000-32767) Limitation of LoadBalancer: 1-to-1 mapping between Service and load-balancer. Expensive! Overcomes the above by exposing multiple Services through a single load-balancer Official (Open) Kubernetes Components summarized abstraction of containers communication route traffic into cluster Official (Open) Config Map & Secret If database URL is hard-coded in the app and you need to adjust: ConfigMap Database URL 1. Re-build the container image username 2. Push it to repo 3. Pull it in the pod password my-app db Secret External configuration of your application Service Service For non-confidential data only Used to store secret data Reference secret in Deployment/Pod Official (Open) ConfigMap Typically used to store non-sensitive configuration data such as : Environment variables Entire configuration files Hostnames Service ports Account names Not to be used to store sensitive data such as certificates and passwords A key/value pair, called an entry Official (Open) Examples of ConfigMap Some simple examples might be: db-port:13306 hostname:msb-prd-db1 More complex examples can store entire configuration files like this: Official (Open) How containers connect to ConfigMap Via any of the following 3 methods: Environment variables Arguments to container’s startup command Files in a volume Official (Open) Environment variables Official (Open) Arguments to container’s startup command Official (Open) Use ConfigMaps with Volumes 1. Create the ConfigMap 2. Create a ConfigMap volume in the Pod template 3. Mount the ConfigMap volume into the container 4. Entries in the ConfigMap will appear in the container as individual files Official (Open) Secrets Almost identical to ConfigMaps Designed for sensitive data such as passwords, certificates and Oauth tokens Official (Open) Kubernetes Components summarized external configuration communication