Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: md lint
Browse files Browse the repository at this point in the history
Signed-off-by: bobz965 <zhangbingbing2_yewu@cmss.chinamobile.com>
bobz965 committed Dec 3, 2024
1 parent 781ecda commit c86c502
Showing 14 changed files with 186 additions and 132 deletions.
5 changes: 3 additions & 2 deletions .github/ISSUE_TEMPLATE/bug-report.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
#

---
name: Bug Report
about: Report a bug encountered

---
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!-->


**What happend**:

**What you expected to happen**:
@@ -16,7 +17,7 @@ about: Report a bug encountered

**Environment**:

- Multus version
- Multus version
image path and image ID (from 'docker images')
- Kubernetes version (use `kubectl version`):
- Primary CNI for Kubernetes cluster:
2 changes: 2 additions & 0 deletions .github/ISSUE_TEMPLATE/enhancement.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
#

---
name: Enhancement Request
about: Suggest an enhancement to multus
2 changes: 2 additions & 0 deletions .github/ISSUE_TEMPLATE/support.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
#

---
name: Support Request
about: Support request or question relating to multus-cni
9 changes: 4 additions & 5 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -62,7 +62,7 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
[The Multus Slack Page](https://intel-corp.herokuapp.com/).
All complaints will be reviewed and investigated promptly and fairly. Or you
may specifically contact Doug Smith (dosmith@redhat.com) via email.
may specifically contact Doug Smith (<dosmith@redhat.com>) via email.

All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
@@ -117,14 +117,13 @@ the community.

This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
<https://www.contributor-covenant.org/version/2/0/code_of_conduct.html>.

Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.

<https://www.contributor-covenant.org/faq>. Translations are available at
<https://www.contributor-covenant.org/translations>.
9 changes: 5 additions & 4 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -20,7 +20,7 @@ used by the Linux kernel project.

Beside the signed-off-by footer, we expect each patch to comply with the following format:

```
```bash
Change summary

More detailed explanation of your changes: Why and how.
@@ -35,15 +35,15 @@ Signed-off-by: <contributor@foo.com>

For example:

```
```bash
Fix poorly named identifiers

One identifier, fnname, in func.go was poorly named. It has been renamed
to fnName. Another identifier retval was not needed and has been removed
entirely.

Fixes #1

Signed-off-by: Abc Xyz <abc.xyz@intel.com>
```

@@ -54,4 +54,5 @@ We accept github pull requests.
## Email and Chat

The project uses the Slack chat:

- Slack: #[Intel-Corp](https://intel-corp.herokuapp.com/) channel on slack
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
@@ -26,7 +26,7 @@ The quickstart installation method for Multus requires that you have first insta

To use latest features try command below which applies a daemonset and installs thick Multus using `kubectl`:

```
```bash
kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset-thick.yml
```

@@ -38,7 +38,7 @@ With the multus 4.0 release, we introduce a new client/server-style plugin deplo

We recommend using the thick plugin in most environments, but if you wish to run the thin plugin, or are in a resource-constrained environment, you may do so with:

```
```bash
kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
```

55 changes: 27 additions & 28 deletions docs/configuration.md
Original file line number Diff line number Diff line change
@@ -12,7 +12,7 @@ Following is the example of multus config file, in `/etc/cni/net.d/`.

Example configuration using `clusterNetwork` (see also [using delegates](#using-delegates))

```
```json
{
"cniVersion": "0.3.1",
"name": "node-cni-network",
@@ -31,7 +31,7 @@ Example configuration using `clusterNetwork` (see also [using delegates](#using-
},
"capabilities": {
"portMappings": true
},
},
"namespaceIsolation": false,
"clusterNetwork": "/etc/cni/net.d/99-flannel.conf",
"defaultNetworks": ["sidecarCRD", "exampleNetwork"],
@@ -51,22 +51,22 @@ This is a general index of options, however note that you must set either the `c
* `cniDir` (string, optional): Multus CNI data directory, default `/var/lib/cni/multus`
* `binDir` (string, optional): additional directory for CNI plugins which multus calls, in addition to the default (the default is typically set to `/opt/cni/bin`)
* `kubeconfig` (string, optional): kubeconfig file for the out of cluster communication with kube-apiserver. See the example [kubeconfig](https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/docs/node-kubeconfig.yaml). If you would like to use CRD (i.e. network attachment definition), this is required
* [`logToStderr`](#Logging-via-STDERR) (bool, optional): Enable or disable logging to `STDERR`. Defaults to true.
* [`logFile`](#Writing-to-a-Log-File) (string, optional): file path for log file. multus puts log in given file
* [`logLevel`](#Logging-Level) (string, optional): logging level (values in decreasing order of verbosity: "debug", "error", "verbose", or "panic")
* [`logOptions`](#Logging-Options) (object, optional): logging option, More detailed log configuration
* [`namespaceIsolation`](#Namespace-Isolation) (boolean, optional): Enables a security feature where pods are only allowed to access `NetworkAttachmentDefinitions` in the namespace where the pod resides. Defaults to false.
* [`globalNamespaces`](#Allow-specific-namespaces-to-be-used-across-namespaces-when-using-namespace-isolation): (string, optional): Used only when `namespaceIsolation` is true, allows specification of comma-delimited list of namespaces which may be referred to outside of namespace isolation.
* [`logToStderr`](#logging-via-stderr) (bool, optional): Enable or disable logging to `STDERR`. Defaults to true.
* [`logFile`](#writing-to-a-log-file) (string, optional): file path for log file. multus puts log in given file
* [`logLevel`](#logging-level) (string, optional): logging level (values in decreasing order of verbosity: "debug", "error", "verbose", or "panic")
* [`logOptions`](#logging-options) (object, optional): logging option, More detailed log configuration
* [`namespaceIsolation`](#namespace-isolation) (boolean, optional): Enables a security feature where pods are only allowed to access `NetworkAttachmentDefinitions` in the namespace where the pod resides. Defaults to false.
* [`globalNamespaces`](#allow-specific-namespaces-to-be-used-across-namespaces-when-using-namespace-isolation): (string, optional): Used only when `namespaceIsolation` is true, allows specification of comma-delimited list of namespaces which may be referred to outside of namespace isolation.
* `capabilities` ({}list, optional): [capabilities](https://github.com/containernetworking/cni/blob/master/CONVENTIONS.md#dynamic-plugin-specific-fields-capabilities--runtime-configuration) supported by at least one of the delegates. (NOTE: Multus only supports portMappings/Bandwidth capability for cluster networks).
* [`readinessindicatorfile`](#Default-Network-Readiness-Indicator): The path to a file whose existence denotes that the default network is ready
* [`readinessindicatorfile`](#default-network-readiness-indicator): The path to a file whose existence denotes that the default network is ready
message to next when some missing error. Defaults to false.
* `systemNamespaces` ([]string, optional): list of namespaces for Kubernetes system (namespaces listed here will not have `defaultNetworks` added)
* `multusNamespace` (string, optional): namespace for `clusterNetwork`/`defaultNetworks` (the default value is `kube-system`)
* `retryDeleteOnError` (bool, optional): Enable or disable delegate DEL
* `retryDeleteOnError` (bool, optional): Enable or disable delegate DEL

### Using `clusterNetwork`

Using the `clusterNetwork` option and the `delegates` are **mutually exclusive**. If `clusterNetwork` is set, the `delegates` field is *ignored*.
Using the `clusterNetwork` option and the `delegates` are **mutually exclusive**. If `clusterNetwork` is set, the `delegates` field is *ignored*.

You **must** set one or the other.

@@ -78,20 +78,20 @@ Therefore:
Options:

* `clusterNetwork` (string, required if not using `delegates`): the default CNI plugin to be executed.
* `defaultNetworks` ([]string, optional): Additional / secondary network attachment that is always attached to each pod.
* `defaultNetworks` ([]string, optional): Additional / secondary network attachment that is always attached to each pod.

The following values are valid for both `clusterNetwork` and `defaultNetworks` and are processed in the following order:

* The name of a `NetworkAttachmentDefinition` custom resource in the namespace specified by the `multusNamespace` configuration option
* The `"name"` value in the contents of a CNI JSON configuration file in the CNI configuration directory,
* The `"name"` value in the contents of a CNI JSON configuration file in the CNI configuration directory,
* The given name for `clusterNetwork` should match the value for `name` key in the contents of the CNI JSON file (e.g. `"name": "test"` in `my.conf` when `"clusterNetwork": "test"`)
* A path to a directory containing CNI json configuration files. The alphabetically first file will be used.
* Absolute file path for CNI config file
* If none of the above are found using the value, Multus will raise an error.

If for example you have `defaultNetworks` set as:

```
```bash
"defaultNetworks": ["sidecarNetwork", "exampleNetwork"],
```

@@ -107,7 +107,7 @@ If `clusterNetwork` is not set, you **must** use `delegates`.

Example configuration using `delegates`:

```
```bash
{
"cniVersion": "0.3.1",
"name": "node-cni-network",
@@ -142,7 +142,6 @@ Only one option is necessary to configure this functionality:

*NOTE*: If `readinessindicatorfile` is unset, or is an empty string, this functionality will be disabled, and is disabled by default.


### Logging

You may wish to enable some enhanced logging for Multus, especially during the process where you're configuring Multus and need to understand what is or isn't working with your particular configuration.
@@ -153,7 +152,7 @@ By default, Multus will log via `STDERR`, which is the standard method by which

Optionally, you may disable this method by setting the `logToStderr` option in your CNI configuration:

```
```json
"logToStderr": false,
```

@@ -163,7 +162,7 @@ Optionally, you may have Multus log to a file on the filesystem. This file will

For example in your CNI configuration, you may set:

```
```json
"logFile": "/var/log/multus.log",
```

@@ -180,7 +179,7 @@ The available logging level values, in decreasing order of verbosity are:

You may configure the logging level by using the `LogLevel` option in your CNI configuration. For example:

```
```json
"logLevel": "debug",
```

@@ -195,7 +194,7 @@ If you want a more detailed configuration of the logging, This includes the foll

For example in your CNI configuration, you may set:

```
```json
"logOptions": {
"maxAge": 5,
"maxSize": 100,
@@ -206,7 +205,7 @@ For example in your CNI configuration, you may set:

### Namespace Isolation

The functionality provided by the `namespaceIsolation` configuration option enables a mode where Multus only allows pods to access custom resources (the `NetworkAttachmentDefinitions`) within the namespace where that pod resides. In other words, the `NetworkAttachmentDefinitions` are isolated to usage within the namespace in which they're created.
The functionality provided by the `namespaceIsolation` configuration option enables a mode where Multus only allows pods to access custom resources (the `NetworkAttachmentDefinitions`) within the namespace where that pod resides. In other words, the `NetworkAttachmentDefinitions` are isolated to usage within the namespace in which they're created.

**NOTE**: The default namespace is special in this scenario. Even with namespace isolation enabled, any pod, in any namespace is allowed to refer to `NetworkAttachmentDefinitions` in the default namespace. This allows you to create commonly used unprivileged `NetworkAttachmentDefinitions` without having to put them in all namespaces. For example, if you had a `NetworkAttachmentDefinition` named `foo` the default namespace, you may reference it in an annotation with: `default/foo`.

@@ -220,7 +219,7 @@ Namespace Isolation is disabled by default.

#### Configuration example

```
```json
"namespaceIsolation": true,
```

@@ -235,7 +234,7 @@ Given the above scenario with a Junior & Senior Administrator. You may assume th

Firstly, we show that we have a number of namespaces available:

```
```bash
# List the available namespaces
[user@kube-master ~]$ kubectl get namespaces
NAME STATUS AGE
@@ -248,7 +247,7 @@ privileged Active 4s

We'll create a `NetworkAttachmentDefinition` in the `privileged` namespace.

```
```bash
# Show the network attachment definition we're creating.
[user@kube-master ~]$ cat cr.yml
apiVersion: "k8s.cni.cncf.io/v1"
@@ -285,7 +284,7 @@ macvlan-conf 11s

Next, we'll create a pod with an annotation that references the privileged namespace. Pay particular attention to the annotation that reads `k8s.v1.cni.cncf.io/networks: privileged/macvlan-conf` -- where it contains a reference to a `namespace/configuration-name` formatted network attachment name. In this case referring to the `macvlan-conf` in the namespace called `privileged`.

```
```yaml
# Show the yaml for a pod.
[user@kube-master ~]$ cat example.pod.yml
apiVersion: v1
@@ -307,7 +306,7 @@ pod/samplepod created

You'll note that pod fails to spawn successfully. If you check the Multus logs, you'll see an entry such as:

```
```bash
2018-12-18T21:41:32Z [error] GetNetworkDelegates: namespace isolation enabled, annotation violates permission, pod is in namespace development but refers to target namespace privileged
```

@@ -317,7 +316,7 @@ In a positive example, you'd instead create the `NetworkAttachmentDefinition` in

A positive example may be:

```
```bash
# Create the same NetworkAttachmentDefinition as above, however in the development namespace
[user@kube-master ~]$ kubectl create -f cr.yml -n development
networkattachmentdefinition.k8s.cni.cncf.io/macvlan-conf created
@@ -350,7 +349,7 @@ samplepod 1/1 Running 0 31s

The `globalNamespaces` configuration option is only used when `namespaceIsolation` is set to true. `globalNamespaces` specifies a comma-delimited list of namespaces which can be referred to from outside of any given namespace in which a pod resides.

```
```json
"globalNamespaces": "default,namespace-a,namespace-b",
```

9 changes: 5 additions & 4 deletions docs/development.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
#

## Development/Support Information

## Which Kubernetes version is supported in multus?
@@ -15,7 +17,7 @@ hence there is no shell command. If you want to execute shell in multus pod, ple
Multus now uses [gopkg.in](http://gopkg.in/) to expose its code as library.
You can use following command to import our code into your go code.

```
```bash
go get gopkg.in/k8snetworkplumbingwg/multus-cni.v4
```

@@ -33,7 +35,7 @@ If an issue is closed that you don't feel is sufficiently resolved, please feel

You can use the built in `./hack/build-go.sh` script!

```
```bash
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git
cd multus-cni
./hack/build-go.sh
@@ -43,7 +45,7 @@ cd multus-cni

Multus has go unit tests (based on ginkgo framework).The following commands drive CI tests manually in your environment:

```
```bash
sudo ./hack/test-go.sh
```

@@ -55,7 +57,6 @@ The following are the best practices for multus logging:
* In case of error handling, use `logging.Errorf()` with given error info
* `logging.Panicf()` only be used for critical errors (it should NOT normally be used)


## Multus release schedule

On the first maintainer's meeting, twice yearly, after January 1st and July 1st, if a new version has not been tagged, a new version will tagged.
114 changes: 78 additions & 36 deletions docs/how-to-use.md

Large diffs are not rendered by default.

34 changes: 17 additions & 17 deletions docs/quickstart.md
Original file line number Diff line number Diff line change
@@ -13,7 +13,7 @@ Two things we'll refer to a number of times through this document are:

## Prerequisites

Our installation method requires that you first have installed Kubernetes and have configured a default network -- that is, a CNI plugin that's used for your pod-to-pod connectivity.
Our installation method requires that you first have installed Kubernetes and have configured a default network -- that is, a CNI plugin that's used for your pod-to-pod connectivity.

We support Kubernetes versions that Kubernetes community supports. Please see [Supported versions](https://kubernetes.io/releases/version-skew-policy/#supported-versions) in Kubernetes document.

@@ -25,13 +25,13 @@ Alternatively, for advanced use cases, for installing Multus and a default netwo

To verify that you default network is ready, you may list your Kubernetes nodes with:

```
```bash
kubectl get nodes
```

In the case that your default network is ready you will see the `STATUS` column also switch to `Ready` for each node.

```
```bash
NAME STATUS ROLES AGE VERSION
master-0 Ready master 1h v1.17.1
master-1 Ready master 1h v1.17.1
@@ -46,14 +46,15 @@ We'll apply a YAML file with `kubectl` from this repo, which installs the Multus

Recommended installation:

```
```bash
kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset-thick.yml
```

See the [thick plugin docs](./thick-plugin.md) for more information about this architecture.

Alternatively, you may install the thin-plugin with:

```
```bash
kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
```

@@ -63,12 +64,11 @@ kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-c
* Reads the lexicographically (alphabetically) first configuration file in `/etc/cni/net.d`, and creates a new configuration file for Multus on each node as `/etc/cni/net.d/00-multus.conf`, this configuration is auto-generated and is based on the default network configuration (which is assumed to be the alphabetically first configuration)
* Creates a `/etc/cni/net.d/multus.d` directory on each node with authentication information for Multus to access the Kubernetes API.


### Validating your installation

Generally, the first step in validating your installation is to ensure that the Multus pods have run without error, you may see an overview of those by looking at:

```
```bash
kubectl get pods --all-namespaces | grep -i multus
```

@@ -82,7 +82,7 @@ The first thing we'll do is create configurations for each of the additional int

Each configuration we'll add is a CNI configuration. If you're not familiar with them, let's break them down quickly. Here's an example CNI configuration:

```
```json
{
"cniVersion": "0.3.0",
"type": "loopback",
@@ -106,15 +106,15 @@ You do not need to reload or refresh the Kubelets when CNI configurations change

So, we want to create an additional interface. Let's create a macvlan interface for pods to use. We'll create a custom resource that defines the CNI configuration for interfaces.

Note in the following command that there's a `kind: NetworkAttachmentDefinition`. This is our fancy name for our configuration -- it's a custom extension of Kubernetes that defines how we attach networks to our pods.
Note in the following command that there's a `kind: NetworkAttachmentDefinition`. This is our fancy name for our configuration -- it's a custom extension of Kubernetes that defines how we attach networks to our pods.

Secondarily, note the `config` field. You'll see that this is a CNI configuration just like we explained earlier.

Lastly but *very* importantly, note under `metadata` the `name` field -- here's where we give this configuration a name, and it's how we tell pods to use this configuration. The name here is `macvlan-conf` -- as we're creating a configuration for macvlan.

Here's the command to create this example configuration:

```
```bash
cat <<EOF | kubectl create -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
@@ -144,13 +144,13 @@ EOF

You can see which configurations you've created using `kubectl` here's how you can do that:

```
```bash
kubectl get network-attachment-definitions
```

You can get more detail by describing them:

```
```bash
kubectl describe network-attachment-definitions macvlan-conf
```

@@ -160,7 +160,7 @@ We're going to create a pod. This will look familiar as any pod you might have c

Let's go ahead and create a pod (that just sleeps for a really long time) with this command:

```
```bash
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
@@ -178,7 +178,7 @@ EOF

You may now inspect the pod and see what interfaces are attached, like so:

```
```bash
kubectl exec -it samplepod -- ip a
```

@@ -192,7 +192,7 @@ You should note that there are 3 interfaces:

For additional confirmation, use `kubectl describe pod samplepod` and there will be an annotations section, similar to the following:

```
```yaml
Annotations: k8s.v1.cni.cncf.io/networks: macvlan-conf
k8s.v1.cni.cncf.io/network-status:
[{
@@ -219,7 +219,7 @@ This metadata tells us that we have two CNI plugins running successfully.

You can add more interfaces to a pod by creating more custom resources and then referring to them in pod's annotation. You can also reuse configurations, so for example, to attach two macvlan interfaces to a pod, you could create a pod like so:

```
```bash
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
@@ -235,6 +235,6 @@ spec:
EOF
```

Note that the annotation now reads `k8s.v1.cni.cncf.io/networks: macvlan-conf,macvlan-conf`. Where we have the same configuration used twice, separated by a comma.
Note that the annotation now reads `k8s.v1.cni.cncf.io/networks: macvlan-conf,macvlan-conf`. Where we have the same configuration used twice, separated by a comma.

If you were to create another custom resource with the name `foo` you could use that such as: `k8s.v1.cni.cncf.io/networks: foo,macvlan-conf`, and use any number of attachments.
3 changes: 2 additions & 1 deletion docs/thick-plugin.md
Original file line number Diff line number Diff line change
@@ -22,7 +22,7 @@ It will then return the result of the operation back to the client.
Please refer to the diagram below for a visual representation of the flow
described above:

```
```txt
┌─────────┐ ┌───────┐ ┌────────┐ ┌──────────┐
│ │ cni ADD/DEL │ │ REST POST │ │ cni ADD/DEL │ │
│ runtime ├────────────►│ shim │===========│ daemon ├────────────►│ delegate │
@@ -76,6 +76,7 @@ as well. By default, it is disabled.
In addition, you can add any configuration which is in [configuration reference](https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/docs/configuration.md#multus-cni-configuration-reference). Server configuration override multus CNI configuration (e.g. `/etc/cni/net.d/00-multus.conf`)

Below you can see an example of the daemon configuration:

```json
{
"chrootDir": "/hostroot",
20 changes: 11 additions & 9 deletions e2e/README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
#

## Multus e2e test with kind

### Prerequisite
@@ -10,17 +12,17 @@ To run the e2e test, you need the following components:

### How to test e2e

```
$ git clone https://github.com/k8snetworkplumbingwg/multus-cni.git
$ cd multus-cni/e2e
$ ./get_tools.sh
$ ./generate_yamls.sh
$ ./setup_cluster.sh
$ ./test-simple-macvlan1.sh
```bash
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git
cd multus-cni/e2e
./get_tools.sh
./generate_yamls.sh
./setup_cluster.sh
./test-simple-macvlan1.sh
```

### How to teardown cluster

```
$ ./teardown.sh
```bash
./teardown.sh
```
34 changes: 18 additions & 16 deletions examples/README.md
Original file line number Diff line number Diff line change
@@ -12,42 +12,42 @@ More specifically, these examples show:

* Multus configured, using CNI a `.conf` file, with CRD support, specifying that we will use a "default network".
* A resource definition with a daemonset that places the `.conf` on each node in the cluster.
* A CRD defining the "networks" @ `network-attachment-definitions.k8s.cni.cncf.io`
* A CRD defining the "networks" @ `network-attachment-definitions.k8s.cni.cncf.io`
* CRD objects containing the configuration for both Flannel & macvlan.

## Quick-start instructions

* Compile Multus and place binaries into (typically) `/opt/cni/bin/`
- Refer to the primary README.md for more details on compilation.
* Refer to the primary README.md for more details on compilation.
* Allow `system:node` access to enable Multus to pull CRD objects.
- See "RBAC configuration section below for details."
* See "RBAC configuration section below for details."
* Create the Flannel + Multus setup with the daemonset provided
- As in: `kubectl create -f multus-with-flannel.yml`
- Optionally, verify that the `/etc/cni/net.d/*.conf` exists on each node.
* As in: `kubectl create -f multus-with-flannel.yml`
* Optionally, verify that the `/etc/cni/net.d/*.conf` exists on each node.
* Create the CRDs
- Create the CRD itself, `kubectl create -f crd.yml`
- Create the network attachment configurations (i.e. CNI configurations packed into CRD objects)
+ `kubectl create -f flannel-conf.yml`
+ `kubectl create -f macvlan-conf.yml`
+ Verify the CRD objects are created with: `kubectl get networks`
* Create the CRD itself, `kubectl create -f crd.yml`
* Create the network attachment configurations (i.e. CNI configurations packed into CRD objects)
* `kubectl create -f flannel-conf.yml`
* `kubectl create -f macvlan-conf.yml`
* Verify the CRD objects are created with: `kubectl get networks`
* Spin up an sample pod
- `kubectl create -f sample-pod.yml`
- Verify that it has multiple interfaces with:
+ `kubectl exec -it samplepod -- ip a`
* `kubectl create -f sample-pod.yml`
* Verify that it has multiple interfaces with:
* `kubectl exec -it samplepod -- ip a`

## RBAC configuration

You'll need to enable the `system:node` users access to the API endpoints that will deliver the CRD objects to Multus.
You'll need to enable the `system:node` users access to the API endpoints that will deliver the CRD objects to Multus.

Using these examples, you'll first create a cluster role with the provided sample:

```
```bash
kubectl create -f clusterrole.yml
```

You will then create a `clusterrolebinding` for each hostname in the Kubernetes cluster. Replace `HOSTNAME` below with the host name of a node, and then repeat for all hostnames in the cluster.

```
```bash
kubectl create clusterrolebinding multus-node-HOSTNAME \
--clusterrole=multus-crd-overpowered \
--user=system:node:HOSTNAME
@@ -62,6 +62,7 @@ A sample `cni-configuration.conf` is provided, typically this file is placed in
Primarily in this setup one thing that one should consider are the aspects of the `macvlan-conf.yml`, which is likely specific to the configuration of the node on which this resides.

## Passing down device information

Some CNI plugins require specific device information which maybe pre-allocated by K8s device plugin. This could be indicated by providing `k8s.v1.cni.cncf.io/resourceName` annotation in its network attachment definition CRD. The file [`examples/sriov-net.yaml`](./sriov-net.yaml) shows an example on how to define a Network attachment definition with specific device allocation information. Multus will get allocated device information and make them available for CNI plugin to work on.

In this example (shown below), it is expected that an [SRIOV Device Plugin](https://github.com/intel/sriov-network-device-plugin/) making a pool of SRIOV VFs available to the K8s with `intel.com/sriov` as their resourceName. Any device allocated from this resource pool will be passed down by Multus to the [sriov-cni](https://github.com/intel/sriov-cni/tree/dev/k8s-deviceid-model) plugin in `deviceID` field. This is up to the sriov-cni plugin to capture this information and work with this specific device information.
@@ -89,6 +90,7 @@ spec:
}
}'
```
The [sriov-pod.yml](./sriov-pod.yml) is an example Pod manifest file that requesting a SRIOV device from a host which is then configured using the above network attachment definition.
>For further information on how to configure SRIOV Device Plugin and SRIOV-CNI please refer to the links given above.
18 changes: 10 additions & 8 deletions images/README.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,13 @@
#

## Dockerfile build

This is used for distribution of Multus in a Docker image.

Typically you'd build this from the root of your Multus clone, as such:

```
$ docker build -t dougbtv/multus -f images/Dockerfile .
```bash
docker build -t dougbtv/multus -f images/Dockerfile .
```

---
@@ -14,8 +16,8 @@ $ docker build -t dougbtv/multus -f images/Dockerfile .

You may wish to deploy Multus as a daemonset, you can do so by starting with the example Daemonset shown here:

```
$ kubectl create -f ./deployments/multus-daemonset.yml
```bash
kubectl create -f ./deployments/multus-daemonset.yml
```

Note: The likely best practice here is to build your own image given the Dockerfile, and then push it to your preferred registry, and change the `image` fields in the Daemonset YAML to reference that image.
@@ -28,7 +30,7 @@ The entrypoint takes named parameters for the configuration

You can get get help with the `--help` flag.

```
```bash
$ ./entrypoint.sh --help

This is an entrypoint script for Multus CNI to overlay its binary and
@@ -47,7 +49,7 @@ in lexicographical order in cni-conf-dir).

You must use an `=` to delimit the parameter name and the value. For example you may set a custom `cni-conf-dir` like so:

```
```bash
./entrypoint.sh --cni-conf-dir=/special/path/to/cni/configs/
```

@@ -59,8 +61,8 @@ Note: You'll noticed that there's a `/host/...` directory from the root for the

Example docker run command:

```
$ docker run -it -v /opt/cni/bin/:/host/opt/cni/bin/ -v /etc/cni/net.d/:/host/etc/cni/net.d/ --entrypoint=/bin/bash dougbtv/multus
```bash
docker run -it -v /opt/cni/bin/:/host/opt/cni/bin/ -v /etc/cni/net.d/:/host/etc/cni/net.d/ --entrypoint=/bin/bash dougbtv/multus
```

Originally inspired by and is a portmanteau of the [Flannel daemonset](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml), the [Calico Daemonset](https://docs.projectcalico.org/manifests/calico.yaml), and the [Calico CNI install bash script](https://github.com/projectcalico/cni-plugin/blob/be4df4db2e47aa7378b1bdf6933724bac1f348d0/k8s-install/scripts/install-cni.sh#L104-L153).

0 comments on commit c86c502

Please sign in to comment.