Express YourSelf !: April 2019

Python Virtual Enviornment

Introduction

The venv module provides support for creating lightweight “virtual environments”. It is optionally isolated from system site directories.

A virtual environment is a Python environment such that
- the Python interpreter,
- libraries and
- scripts
installed into it are isolated from (1) those installed in other virtual environments, and (2) (by default) any libraries installed in a “system” Python, i.e., one which is installed as part of your operating system.

A virtual environment is a directory tree which contains Python executable files and other files which indicate that it is a virtual environment. The path to this folder can be printed with variable
sys.prefix
sys.exec_prefix
These variables are used to locate site packages directory.

Each virtual environment has its own
- Python binary (which matches the version of the binary that was used to create this environment)
- independent set of installed Python packages in its site directories.

Packages (Modules)

Check installed packages using
pip list

Check specific package is installed or not using
pip show "package name"

Two types of packages
1. System packages (installed as part of Python installation)
2. Site packages (3rd party libraries)

Reinstall using
pip install --upgrade --no-deps --force-reinstall "package name"

Pip can export a list of all installed packages and their versions using the freeze command:
pip freeze
This can be used to create requirements.txt file, that is used later as :
pip install -r requirements.txt

Commands

To create venv
python3 -m venv /path/to/new/virtual/environment
c:\>c:\Python35\python -m venv c:\path\to\myenv

To activate venv
source /bin/activate
C:\> \Scripts\activate.bat
It modifies PATH variables. Add the venv path at the beginning.

To deactivate venv
source /bin/deactivate
C:\> \Scripts\deactivate.bat
It reset back PATH variables

To change Python version
pyenv local 2.x
pyenv local 3.x
pyenv global 2.x
pyenv global 3.x

K8s Operator

Introduction

* An Operator is a method of
- packaging,
- deploying and
- managing
a Kubernetes application

Here a Kubernetes application is an application that is both
- deployed on Kubernetes and
- managed by Kubernetes
using the Kubernetes APIs and kubectl tooling.

* Operators are like runtime for K8s application

* Operators are more relevant for stateful applications. like
- databses
- caches
- Machine Learning
- Analytics
- monitoring systems

* Application native/specific. Operator is application specific controller, that extends k8s API for
- packaging (Helm can use to package multiple k8s apps, that will be deployed and managed by their respective operator).
- installation / deployment on k8s cluster
- run
- configure / re-configure
- updates
- upgrades
- rollback, in case of failure
- recover from fault
- backup
- Restore
- scaling
- Monitoring
- self-service provisioning capabilities,
- more complex automation
of application. (particularly stateful applications). Operator does all these without data loss and without application unavailability.

* Operator is like = Custom Resource Definition CRD + its controller. Here the custom resource is application instance. CRD adds new API for the application instance. Controller adds new behavior.

* Operator is like = A set of cohesive APIs to extend K8s functionalities. This code does not go back to k8s repository.

* operator is issued by coreos and the controller is used in Kubernetes. An Operator is an application-specific controller

* Kubernetes Operators are processes connecting to the master API and watching for events, typically on a limited number of resource types.
When a relevant event occurs, the operator reacts and performs a specific action. This may be limited to interacting with the master API only, but will often involve performing some action on some other systems (this could be either in cluster or off cluster resources). * CRD is nativae way of explaining k8s object.

* The kubectl commands work with CRD objects.

* K8s manages K8s objects. With operator, k8s manage multiple application instances across multiple clusters.

* An operator is a way of building an application and driving an application on top of Kubernetes, behind Kubernetes APIs. Operator is more than K8s primitives like StateFulSet and PVC. Operator uses ReplicaSet, Services, DaemonSets, Deployments

* Operator takes human operational knowledge (Read : DevOps Team's knowledge OR Site Reliability Engineer's knowledge about application lifecycle) and put it into software to easily package and share with consumers. This operational knowledge is embedded in CRD itself.

* Operator is like a Controller that uses a CRD to encapsulate operational knowledge for a specific application

* As per Extending K8s article, K8s has multiple extension points as below figure

1. kubectl plugin

2. API access extension

3. CR

4. Scheduler extension

5. Controller. Controller often uses CR

6. Network plugin (CNI Calico)

7. Storage plugin (CSI Portwoks)

We should add Runtimeclass also.

Operator is (3) CR + (5) controller

* Here controllers have direct access to K8s API. So they can monitor the cluster, change pods/services, scale up/down and call endpoints of the running applications, all according to custom rules written inside those controllers.

* a custom controller acts and listens on native Kubernetes resources and events, an Operator works with Custom Resource Definitions (CRDs), resources that the user creates to solve complex business problems.

* Out of 4 najor modules of controller code generator (1) informer-gen and (2) list-gen modules are also called operator. They build basis of custom controller.

* A powerful feature of an Operator is :
to enable the desired state to be reflected in your application.
As the application gets more complicated with more components, detecting these changes can be harder for a human, but easier for a computer.

* One can use existing tools to write your own operator. (Kubebuilder and Operator - SDK focus more on reconcile loop of custom controller)

1. KUDO (Kubernetes Universal Declarative Operator)
https://kudo.dev/
https://github.com/kudobuilder/operators

2. kubebuilder
https://book.kubebuilder.io/
https://github.com/operatify/operatify
Kubebuild is by Google

3. Metacontroller along with WebHooks that you implement yourself

https://metacontroller.app/

4. Operator Framework OR Operator - SDK

Operator Framework is by RedHat OpenShift (now IBM)

4.1. Operator SDK: Set of tools to accelerate the development of an Operator.
Here is CLI guide https://github.com/operator-framework/operator-sdk/blob/master/doc/sdk-cli-reference.md
Here is user guide : https://github.com/operator-framework/operator-sdk/blob/master/doc/user-guide.md

We can run our operator, outside the k8s cluster also as pretest.

4.2. Operator Life Cycle Management

4.3. Operator Metering

Here is K8s core API to write custom code for operator

https://godoc.org/k8s.io/api/core/v1

Operator can be developed using
- GoLang
- Ansible Playbooks
- Helm Charts. It is more specific to stateless K8s application. Here deeper inspection to Pods, Services, Deployments and ConfigMaps will not happen

Types of Custom Resource Definition CRD
1. primary resources
2. secondary resources

* For ReplicaSet, primary resource is ReplicaSet itself docker image and secondary resource is pod
* For DaemonSet, primary resource is DaemonSet itself and secondary resource is pod+node
* For PodSet, primary resource is PodSet itself and secondary resource is pod.

PodSet owns the pod with controllerutil.SetControllerReference()

PodSet will be developed, that is similar to ReplicaSet.

Controller

Controller works like this pseudo code.

while True {
values = check_real_values()
tune_system(values, expected_state)
}

Controller is Informer + downstream store
Another such agent is SharedInformer. It creates shared cache of the state for multiple request.