GitBook: [master] one page and 5 assets modified

This commit is contained in:
CPol 2021-04-26 15:29:19 +00:00 committed by gitbook-bot
parent 00cc0765ca
commit 09a1e84141
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
6 changed files with 9 additions and 5 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 206 KiB

After

Width:  |  Height:  |  Size: 184 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 206 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 75 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 75 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 184 KiB

View File

@ -27,10 +27,13 @@ Security tips for Kubernetes
* **Node**: operating system with pod or pods.
* **Pod**: Wrapper around a container or multiple containers with. A pod should only contain one application \(so usually, a pod run just 1 container\). The pod is the way kubernetes abstracts the container technology running.
* **Service**: Each pod has 1 service attached, which is 1 **IP address**. It's goal is to maintain the communication between pods even if one dies and a new copy is run. It can be configured as internal or external. The service also actuates as a **load balancer when 2 pods are connected** to the same service.
* **Kubelet**: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods \(through API server\). The kubelet doesnt manage containers that were not created by Kubernetes.
* **Kube-proxy**: is the service in charge of the communications \(services\) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
* **Sidecar container**: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
* **Service**: Each pod has 1 internal **IP address** from the internal range of the node. However, it can be also exposed via a service. The **service has also an IP address** and its goal is to maintain the communication between pods so if one dies the **new replacement** \(with a different internal IP\) **will be accessible** exposed in the **same IP of the service**. It can be configured as internal or external. The service also actuates as a **load balancer when 2 pods are connected** to the same service. When a **service** is **created** you can find the endpoints of each service running `kubectl get endpoints`
![](../.gitbook/assets/image%20%28466%29.png)
* **Kubelet**: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods \(through API server\). The kubelet doesnt manage containers that were not created by Kubernetes.
* **Kube-proxy**: is the service in charge of the communications \(services\) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
* **Sidecar container**: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
* **Master process:**
* **Api Server:** Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed.
* **Scheduler**: Scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. It has enough intelligence to decide which node has more available resources the assign the new pod to it. Note that the scheduler doesn't start new pods, it just communicate with the Kubelet process running inside the node, which will launch the new pod.
@ -125,6 +128,7 @@ kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints
#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
@ -342,7 +346,7 @@ helm search <keyword>
Helm is also a template engine that allows to generate config files with variables:
![](../.gitbook/assets/image%20%28463%29.png)
![](../.gitbook/assets/image%20%28465%29.png)
## PART 2 - VULNERABILITIES and some fixes.