Skip to content

Commit 9b03a6c

Browse files
authored
Merge pull request #279 from polycube-network/frisso-docs
Improved docs
2 parents d65c5a4 + 37c1eed commit 9b03a6c

34 files changed

+671
-611
lines changed

Documentation/README.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,12 @@ cd Documentation
1616
pip install -r requirements.txt
1717
```
1818

19+
### Edit it
20+
21+
Documentation is created in the ReSTructured text format.
22+
A nice document listing important commands is the [Restructured Text (reST) and Sphinx CheatSheet](https://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html).
23+
24+
1925
### Build it
2026

2127
```

Documentation/components/index.rst

Lines changed: 0 additions & 9 deletions
This file was deleted.

Documentation/components/iptables/architecture.rst

Lines changed: 0 additions & 10 deletions
This file was deleted.

Documentation/components/iptables/pcn-iptables.rst

Lines changed: 19 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -61,8 +61,8 @@ Prerequisites
6161
pcn-iptables comes as a component of polycube framework.
6262
Refer to :doc:`polycube install guide<../../../installation>` for dependencies, kernel requirements and basic checkout and install guide.
6363

64-
Install Steps
65-
^^^^^^^^^^^^^
64+
Install
65+
^^^^^^^
6666

6767
To compile and install ``pcn-iptables``, you should enable the ``ENABLE_PCN_IPTABLES`` flag in the polycube CMakeFile, which is set to ``OFF`` by default;
6868
this allows to compile the customized version of ``iptables`` used to translate commands, and install in the system pcn-iptables-init pcn-iptables and pcn-iptables-clean utils.
@@ -160,14 +160,29 @@ Limitations
160160
pcn-iptables components
161161
-----------------------
162162

163+
``pcn-iptables`` is composed by three main components:
164+
165+
1. ``pcn-iptables`` service (``src/services/pcn-iptables``): a Polycube service, a special one since performs some extra work, but basically expose its API and CLI, according to Polycube standard.
166+
163167
iptables submodule
164168
^^^^^^^^^^^^^^^^^^
165169

166170
A customized fork of iptables is included as submodule under :scm_web:`src/components/iptables/iptables <src/components/iptables>`.
167-
We customized this version of iptables in order not to inject iptables command into netfilter, but convert them, after a validation step, into polycube syntax.
171+
This modified version of iptables is in charge of validate commands, translate them from iptables to polycube syntax, then forward them to pcn-iptables service instead of pushing them into the kernel via netfilter.
168172

169173
scripts folder
170174
^^^^^^^^^^^^^^
171175

172176
Scripts are used as a glue logic to make pcn-iptables run. Main purpose is initialize, cleanup and run pcn-iptables, pass pcn-iptables parameters through iptables (in charge of converting them), then pass converted commands to pcn-iptables service.
173-
Scripts are installed under ``/usr/local/bin``.
177+
Scripts are installed under ``/usr/local/bin``.
178+
179+
pcn-iptables components
180+
-----------------------
181+
182+
``pcn-iptables`` is composed by three main components:
183+
184+
1. ``pcn-iptables`` service (``src/services/pcn-iptables``): a Polycube service that is especially tailored to work with the ``pcn-iptables`` executable; as usual, it exposes its API and CLI according to Polycube standard.
185+
186+
2. ``iptables*`` (``src/components/iptables/iptables``): a modified version of iptables, in charge of validate commands, translate them from iptables to polycube syntax, then forward them to pcn-iptables service instead of push them into the kernel via netfilter.
187+
188+
3. ``scripts`` (``src/components/iptables/scripts``): this is a folder containing some glue logic and scripts to initialize, cleanup and use ``pcn-iptables``. ``pcn-iptables`` itself is a script that forwards commands to ``iptables*`` (2), then forwards the translated command to ``pcn-iptables`` (1). Scripts are installed under ``/usr/local/bin``.

Documentation/components/k8s/developers.rst

Lines changed: 174 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,177 @@
1-
pcn-k8s Developers
2-
==================
1+
Information for developers
2+
==========================
3+
4+
Controllers
5+
-----------
6+
7+
Controllers are entities that are in charge of providing you with the resource that you need, as well as watch for events and notify when one has occurred.
8+
In Polycube, five controllers are implemented:
9+
10+
- ``Kubernetes Network Policies``
11+
- ``Polycube Network Policies``
12+
- ``Services``
13+
- ``Namespaces``
14+
- ``Pods``
15+
16+
Not all of them provide the same functionalities and filtering criteria, but all work based on the same principle.
17+
18+
19+
Usage
20+
^^^^^
21+
22+
The usage is inspired by Kubernetes' API style.
23+
To use the controllers, you simply need to import the ``pcn_controllers`` package and call the controller you'd like to use.
24+
Take a look at the following examples.
25+
26+
.. code-block:: go
27+
28+
package main
29+
import (
30+
// importing controllers
31+
pcn_controllers "github.com/polycube-network/polycube/src/components/k8s/pcn_k8s/controllers"
32+
)
33+
34+
func main() {
35+
// Namespaces
36+
namespaces, err := pcn_controllers.Namespaces().List(...)
37+
38+
// Pods
39+
unsubscriptor, err := pcn_controllers.Namespaces().Subscribe(...)
40+
41+
// etc...
42+
}
43+
44+
45+
Queries
46+
^^^^^^^
47+
48+
All controllers can retrieve resources from the Kubernetes cache, based on some criteria.
49+
To define criteria, you must define the query: the definition is in package ``pcn_types``:
50+
51+
.. code-block:: go
52+
53+
// ObjectQuery is a struct that specifies how the object should be found
54+
type ObjectQuery struct {
55+
By string
56+
Name string
57+
Labels map[string]string
58+
}
59+
60+
Take a look at the following examples:
61+
62+
.. code-block:: go
63+
64+
// I want resources that are named "my-service"
65+
serviceQuery := pcn_types.ObjectQuery {
66+
By: "name",
67+
Name: "my-service",
68+
}
69+
70+
// I want all pods that have labels "app: my-app", and "role: database"
71+
podQuery := pcn_types.ObjectQuery {
72+
By: "labels",
73+
Labels: map[string]string {
74+
"app": "my-app",
75+
"role": "database",
76+
}
77+
78+
Although you can create these by hand, a convenient function exists to do this and it is specifically made for use with the controllers:
79+
80+
.. code-block:: go
81+
82+
import (
83+
"github.com/polycube-network/polycube/src/components/k8s/utils"
84+
)
85+
86+
// ...
87+
88+
// Build a "by: name" query
89+
serviceQuery := utils.BuildQuery("my-service", nil)
90+
91+
// Build a "by: labels" query
92+
podQuery := utils.BuildQuery("my-service", map[string]string {
93+
"app": "my-app",
94+
"role": "database",
95+
})
96+
97+
// Build a query to get all resources, regardless of name and labels
98+
allResources := utils.BuildQuery("", nil)
99+
100+
This function returns a **pointer** to the actual query structure because that's what controllers need. When wanting to get all resources, the function returns nil, so you may even just use a nil value without calling the BuildQuery function.
101+
102+
103+
List resources
104+
^^^^^^^^^^^^^^
105+
106+
To list resources, you need to first create the queries, and then call the **List** function of the controller.
107+
Not all controllers support both name and label criteria: i.e. the Pod Controller only supports labels.
108+
109+
.. code-block:: go
110+
111+
// I want all services that apply to pods with labels "app: my-app" and "role: db"
112+
// and are on a namespace called "production"
113+
// So, first create the queries for both the service and namespace.
114+
serviceQuery := utils.BuildQuery(nil, map[string]string {
115+
"app": "my-app",
116+
"role": "db",
117+
})
118+
119+
nsQuery := utils.BuildQuery("production", nil)
120+
// Then, get them. Note: there might be more than one service which applies to those pods.
121+
servicesList, err := pcn_controllers.Services().List(serviceQuery, nsQuery)
122+
if err != nil {
123+
return
124+
}
125+
for _, service := range servicesList {
126+
// Do something with this service...
127+
}
128+
129+
So, usually, the first argument is criteria about the resource, while the second is reserved for criteria about the namespace where you want to find such resources.
130+
131+
To give additional information:
132+
133+
- The ``Kubernetes Network Policies`` and ``Polycube Network Policies`` controllers only support querying the policy by name
134+
- The ``Pod`` controller only supports querying by labels
135+
- The ``Pod`` controller also supports a third argument for the node where you want this pod to be located.
136+
- The ``Services`` controller supports both name and labels, but when using labels it searches for them in the **spec.selector** field, not those under its metadata.
137+
- The ``Namespaces`` controller work with namespaces, which cannot belong to other resources and only want one argument.
138+
139+
Note that, according to the criteria, it may take you a long time to get the results. Whenever possible, or when you expect a query to return lots of resources, adopt an async pattern or use multiple goroutines.
140+
141+
142+
Watch for events
143+
^^^^^^^^^^^^^^^^
144+
145+
To watch for events, you need to use a controller's ``Subscribe`` function by passing to it the event type you want to monitor, the resource criteria, and the function to be executed when that event is detected.
146+
147+
.. code-block:: go
148+
149+
func firstfunc() {
150+
// I want to "myfunc" to be notified whenever a new pod is born.
151+
// Pod controller has the most complex subscribe function, as it also asks you for the phase of the pod.
152+
unsub, err := pcn_controllers.Pods().Subscribe(pcn_types.New, nil, nil, &pcn_types.ObjectQuery{Name: "node-name"}, pcn_types.PodRunning, myfunc)
153+
154+
// ...
155+
156+
// I am not interested in that event anymore
157+
unsub()
158+
}
159+
160+
func myfunc(currentState, previousState *core_v1.Pod) {
161+
// Do something with it...
162+
}
163+
164+
As the above example shows, the ``Subscribe`` function returns a pointer to a function that you need to call when you're not interested in that event anymore.
165+
166+
The function to execute must always have two arguments: the current state of the object and its previous state. There are three event types: ``New``, ``Update``, ``Delete``.
167+
168+
Just some heads up:
169+
170+
- When monitoring ``New`` events, only the current state of the object is present, the previous is obviously always ``nil``.
171+
- When monitoring ``Delete`` events, the object does not exist anymore, so the current state is always ``nil``.
172+
173+
All the ``Subscribe`` functions share a similar structure to the ``List`` function in the same controller, to make sure about their usage, check their definitions in the ``pcn_controllers`` package
174+
3175

4176
Creating the Docker Images
5177
--------------------------
@@ -12,8 +184,3 @@ Docker 18.06 is needed to build the images, and the daemon has to be started wit
12184
export DOCKER_BUILDKIT=1 # flag needed to enable the --mount option
13185
docker build --build-arg DEFAULT_MODE=pcn-k8s -t name:tag .
14186
docker push name:tag
15-
16-
17-
Networking policy controller
18-
----------------------------
19-
Refer to :doc:`Controller development <polycube_controllers>`.
Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
pcn-k8s: a network provider for kubernetes
2+
==========================================
3+
4+
.. toctree::
5+
:maxdepth: 3
6+
:caption: Contents:
7+
8+
pcn-kubernetes
9+
kubernetes-network-policies
10+
polycube-network-policies
11+
developers

0 commit comments

Comments
 (0)