Cloud - IT

If our log directory "/var/log " is using up a lot of disk space, we could check the files that are consuming the space using the below command: The above command lists all of the fi les sorted by their size. We could erase the content of these files using the below command: If one of the large files was rotated, it will have the " .3 " or " .2 " appended to it. We could also change the settings of the " logrotate " in the following files " /etc/logrotate.conf " and " /etc/logrotate.d/ " so that the rotated logs will be compressed. Remark: Log rotation is a system that allows files to be compressed, renamed and ultimately deleted after their retention period is up.

A list is a collection of val ues stored in memory. A generator does not build a list, it only tells us how to generate these values with nothing stored in memory. Our examples below use the " range() " iterator and they produce the same results. Below is our list example: And our generator example: The generator expression generate values only when they are needed which saves us system resources, especially with huge amounts of data.

Names that start and end with two underscores - __var__ - are internal names used by python like - __init__ , __str__ -. Names that start with an underscore - _var - are not imported into other programs using the - from ... import ... - instruction. They are meant to be used within the program as " internals ": Names that start with two underscores - __var - inside a class get prefixed with the class name: The " __var " variable becomes " _A__var ". The name that is represented by single underscore - _ - is used by python to store the result of the last result, for example to go through a loop where the index is of no use to us: Names with a trailing underscore - var_ - are usually used so the name doesn't get mixed up with a python keyword.

Kubernetes "converts" its services and pods/endpoints into a ServiceEntry through Istio .   A service with two pods and two endpoints -  10.244.3.1, 10.244.3.2 -,  will be mapped to a ServiceEntry - host / IP address endpoint -. Endpoints  represent the IP addresses that a service sends its requests to. The "hosts" in the  ServiceEntry   Yaml file are associated with the service. A ServiceEntry adds newly added services to the service registry - database of existing services in Istio -, this allows existing services to be able to access these newly deployed ones. Below is an example of a service its endpoint and the resulting service entry : We have two nginx pods and the service entry that allows access through the host " service1.default.svc.cluster.local " to  the nginx applications.

We have the below destination rule for routing traffic to the containerized application " application1"  : We create VirtualService so that all the traffic goes to our application " application1 ": In the above  VirtualService all traffic goes to " application1 ". The below DestinationRule has an effect on " application1 " and all its traffic. To avoid having lot of requests going to our pods and slowing down the application running inside, we set a circuit breaker that will stop requests when a pod is handling more than two requests at the same time -   http1MaxPendingRequests -. We can create a circuit breaker for our service using a destination rule as follows: Above is the configuration file for a circuit breaker for any client applications making  a request to the " application1 "  of the " svc1.ns1.svc.cluster.local " service.  We are putting a cap on the number of connections and number of pending requests to ...

Istio provides loadbalancing for kubernetes . It also supports retries for failing pods and circuit breaking to reject requests for pods with a " degraded " service. It also provides it with " pool ejection ", which stops pods and removes them as a destination for the loadbalancer . Below is an example of kubernetes without Istio: The below diagram shows kubernetes with Istio : Some of the functions of the the proxy sidecar include: packet forwarding. routing. caching. loadbalancing. Below is a basic " RANDOM " loadbalancing rules for our service: We could use the VirtualService to implement a timeout for our service in case it fails, so the client application would just sit around waiting for a service that has failed: We could use the retry feature of Istio to can make more attempts to try to connect to an unresponsive service. Using a VirtualService , we could specify the " retry " parameter: The above  VirtualService  make " 5 " at...