projectcalico / calico Goto Github PK
View Code? Open in Web Editor NEWCloud native networking and network security
Home Page: https://docs.tigera.io/calico/latest/about/
License: Apache License 2.0
Cloud native networking and network security
Home Page: https://docs.tigera.io/calico/latest/about/
License: Apache License 2.0
The configuration page currently talks about system and Felix configuration but it doesn't talk about calicoctl or how to set config values.
I think we should have a landing page that gives an overview of the different types of configuration we support and why you'd want to tweak each of them (System requirements; Felix; BGP; integration-specific) and fans people out to more detailed docs.
/index.html
has a hardcoded redirect to the latest release (currently v1.5).
We should softcode this.
This issue may affect #77
This page makes heavy use of note:
boxes: https://tigera.github.io/calico/0_1/reference/etcd/data-model
Right now they're formatted as subheadings. They should be wrapped in a coloured box.
This question is frequently asked, and we have an answer!
A vlink colour that contrasts more with black would be nice.
Perhaps a bit lighter, although I'm not sure people would want it to be pink? WDYT?
From @robbrockbank on January 4, 2016 23:54
The links from the projectcalico.org site (http://www.projectcalico.org/getting-started/) could do with a substantial re-work to better reflect the variety of options available in calico-containers.
Copied from original issue: projectcalico/calico-containers#708
There are a number of independent studies on container networking perf which feature Calico. Would be nice if we could collect those in one place so they are easy to find, as per a user request on Slack.
Doesn't discuss the IP address mobility and aggregation issues. Also need to clean up the AS's at the TOR layer.
Go to: https://www.projectcalico.org/
click on Documentation
bam: 404
it should point to http://docs.projectcalico.org/master/introduction/
It points to http://docs.projectcalico.org/en/latest/index.html
right now.
From @matthewdupre on March 23, 2016 21:54
We now support a new way to configure etcd's location: ETCD_ENDPOINTS (see #882).
This should be added to the documentation.
Copied from original issue: projectcalico/calico-containers#889
The URL is /calico-docs/master/using-calico
, when it should be /calico-docs/master/usage
The docs site could use improvements to its theme that accomplishes the following:
Should we include the instructions in this readme in our documentation or remove the reference?
[Reference was in the quick start kubernetes.md guide.]
... when we reorg the docs, make sure the links to the Juju bundles (if we keep the section on Juju) are correct and include the bundles for Liberty/Mitaka.
From @djosborne on July 6, 2016 16:3
Our Dockerless Calico guide has fallen out of date, namely with the introduction of startup.py
.
Copied from original issue: projectcalico/calico-containers#1041
It would be great to have something a little flashy on the front page with badges highlighting our support platforms (e.g. OpenStack Mitaka, Kubernetes XXX). Not quite sure, though, how easy it will be to provide something concise (e.g. for OpenStack, technically we support icehouse, Kilo, Liberty and Mitaka).
So that users who come to Calico understand the value proposition that Calico offers and the use-cases it tries to solve.
It is important that people who are new to Calico understand why someone would want to use it, as well as how it works. This probably serves twofold:
Note that this may be a global document and/or individual documents per-orchestrator, to advertise the features that Calico brings to each environment.
right now it only lists the repos with latest
as version, it might be a good idea to add links to the repos in one place.
The page under References > Repo structure doesn't have it in a list format and isn't an obvious location a user would look, but Releases
tab seems like a good place to have those links there
From @caseydavenport on February 3, 2016 0:50
I can't find any documentation that describes Calico's IPAM behavior and how it interacts with pools. This would be useful info for Calico users to have.
Copied from original issue: projectcalico/calico-containers#784
TL;DR: sent packet from Jenkins server to VM IP address that wasn't in compute node's routing table yet; packet got forwarded to default LAN gateway even though it was for an address in the IP pool. Should we black-hole such traffic instead?
We hit this in the test rig; I'm not 100% sure if it's relevant in a real deployment. We're using subnets of 10/8 for our various network IP pools and we have our jenkins test server set up with a static route for all of 10/8 that goes to one of the compute nodes. Jenkins creates a network, and adds a VM into it then it tries to ssh into the VM.
There is a race where the ssh TCP packets get to the compute node before the route to the VM is in place and until the route is in place, the compute node seems to forward packets that were destined for the VM to its default gateway, which is on our internal LAN.
Since the internal LAN has some routes to (a different) 10/8 (I know, we're being naughty re-using addresses), our packets end up forwarded round the houses and come back (as dest unreachable) via a different route. I think that incorrect route then gets cached causing further problems (we were seeing Jenkins trying to send packets to the VM via the default gateway instead of via the compute node).
We have a Route Reflector container in our bird fork. We should consider including those docs in here.
https://github.com/projectcalico/calico-bird/tree/feature-ipinip/build_routereflector
From @caseydavenport on June 17, 2016 16:20
We set up the following routes within a container to get traffic out to the host:
default via 169.254.1.1 dev eth0
168.254.1.1 dev eth0
We should document this so that it isn't confusing / surprising to users.
Copied from original issue: projectcalico/calico-containers#1023
In the current branding, the social buttons are somewhat "kubernetes blue". We should change the /images/social-sprite.png to be more Calico Orange (#f69432).
Now that most of our documentation is located in one place, we should revisit each repository and ensure it has the correct documents in it. This means coming up with a plan for how we display (for example):
We should also which (shared) information should be placed in the new docs site
From @robbrockbank on February 8, 2016 19:23
The involved.rst document currently points at calico-docker.
etc.
Copied from original issue: projectcalico/felix#976
If we're calling this repo "calico" a bunch of people are going to end up here first. They need to be guided to the right place
From @matthewdupre on March 16, 2016 16:44
We should review the intro slide deck and put any useful diagrams into the docs: this should be pitched at someone about the level of "someone told me Calico was cool: what is it?".
Copied from original issue: projectcalico/felix#994
See this user that had problems - http://stackoverflow.com/questions/39861422/starting-calicoctl-container-on-coreos/39861794#39861794
A lot of the information in https://github.com/tigera/calico/blob/master/master/using-calico/troubleshooting/index.md is container-centric.
For example, calicoctl
isn't used on Openstack, and neither is confd
. Should this doc be here at all? Perhaps the information contained within it would be better placed into the -Troubleshooting docs ?
From @djosborne on May 18, 2016 16:43
Our Libnetwork Documentation doesn't show an example for launching a calico with Calico IPAM on a particular subnet.
We should provide information on it, including the known restriction that "the --subnet
you specify must precisely match a pool you've created.
Copied from original issue: projectcalico/calico-containers#991
Currently, it goes into detail about how the data is stored in etcd.
The docs should discuss the higher-level "libcalico" concepts. There can still be a doc which discusses the specifics of the etcdv2 / etcdv3 / etc implementations, but it should be separate (either as separate docs on the site, or as markdown files in the libcalico repo (since it is highly technical).
In the ubuntu and Red Hat openstack install docs, there is a reference to http://wiki.libvirt.org/page/Guest_won't_start_-_warning:_could_not_open_/dev/net/tun_('generic_ethernet'_interface) which appears to no longer exist.
We should investigate SEO with robots.txt
Tigera have its own Vimeo site where we can get stats, etc. for any of our videos. We should put a copy of the Network Policy demo from /docs/getting-started/kubernetes/calico-kubernetes-overview there and embed it in the document.
I find there a lot of users in the slack channel who haven't fully grocked Calico philosophy, so they're ask narrow questions based on a larger misconception. I'm opening this issue to track a running list of these common questions:
Question: How do I choose which pool my task is assigned an IP from?
Often users are asking this question for the wrong reason. Different pools are only really necessary when choosing which routes to broadcast beyond the TOR. Pool selection should never be used to enforce policy.
The newline spacing between different topics in markdown doesn't get translated into newlines the final HTML.
For example: https://tigera.github.io/calico/master/reference/architecture/
Notice the line spacing between on that, see this document.
and #Components
From @fasaxc on September 8, 2016 9:44
As per https://github.com/projectcalico/felix/issues/1027, felix and OpenStack can disagree on the hostname. This was awkward to track down, maybe we can enhance the docs or add some heuristics to felix to spot the situation.
Copied from original issue: projectcalico/felix#1096
The versioned dropdown selector at the top-right is hardcoded in docwithnav.html
. We should consider a cleaner approach to this.
Much of the versioned components of the site are done based on the variable set in _config.yml
for the cwd. This method can't easily be applied to pieces of the site that point to other versions. We need a different method.
One suggestion is to add a yaml file to the toplevel _data
which describes the available versions. Then docwithnav can render the dropdown based on the file.
From @tomdee on September 1, 2016 19:44
Copied from original issue: projectcalico/calico-containers#1142
There are various warning boxes on this page: http://docs.projectcalico.org/v1.5/reference/etcd/data-model
Right now, they're run in with the text rather than being styled as a box, for example.
As an improvement on running calico-node as a docker daemon (with the associated chicken-egg problem with calico-libnetwork), we've been looking at running it as a simple docker-runc
service instead. This has the benefit of being easier to stream into a disk image on first provisioning, and running more natually as an init job rather then a docker job.
Unfortunately, the existing calico-node
container is quite badly organized for this task, assuming that a large number of endpoints are writeable which probably shouldn't be.
As a first pass, this is a configuration (derived from the docker one) which works for me (with a read-only calico-node blob):
EDIT: Updated the calico blob with the one I'm using for calico-node 1.0.0beta
.
{
"hooks": {},
"hostname": "runc",
"linux": {
"maskedPaths": [
"/proc/kcore",
"/proc/latency_stats",
"/proc/timer_stats",
"/proc/sched_debug"
],
"namespaces": [
{
"type": "pid"
},
{
"type": "ipc"
},
{
"type": "uts"
},
{
"type": "mount"
}
],
"readonlyPaths": [
"/proc/asound",
"/proc/bus",
"/proc/fs",
"/proc/irq",
"/proc/sys/abi",
"/proc/sys/debug",
"/proc/sys/dev",
"/proc/sys/fs",
"/proc/sys/kernel",
"/proc/sys/vm",
"/proc/sysrq-trigger"
],
"resources": {
"devices": [
{
"access": "rwm",
"allow": true
}
]
}
},
"mounts": [
{
"destination": "/proc",
"options": [
"nosuid",
"noexec",
"nodev"
],
"source": "proc",
"type": "proc"
},
{
"destination": "/dev",
"options": [
"nosuid",
"strictatime",
"mode=755",
"size=65536k"
],
"source": "tmpfs",
"type": "tmpfs"
},
{
"destination": "/dev/pts",
"options": [
"nosuid",
"noexec",
"newinstance",
"ptmxmode=0666",
"mode=0620",
"gid=5"
],
"source": "devpts",
"type": "devpts"
},
{
"destination": "/dev/shm",
"options": [
"nosuid",
"noexec",
"nodev",
"mode=1777",
"size=65536k"
],
"source": "shm",
"type": "tmpfs"
},
{
"destination": "/dev/mqueue",
"options": [
"nosuid",
"noexec",
"nodev"
],
"source": "mqueue",
"type": "mqueue"
},
{
"destination": "/sys",
"options": [
"nosuid",
"noexec",
"nodev",
"ro"
],
"source": "sysfs",
"type": "sysfs"
},
{
"destination": "/sys/fs/cgroup",
"options": [
"nosuid",
"noexec",
"nodev",
"relatime",
"ro"
],
"source": "cgroup",
"type": "cgroup"
},
{
"destination": "/lib/modules",
"options": [
"rbind",
"rprivate"
],
"source": "/lib/modules",
"type": "bind"
},
{
"destination": "/var/log/calico",
"options": [
"rbind",
"rprivate"
],
"source": "/var/log/calico",
"type": "bind"
},
{
"destination": "/var/run/calico",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico",
"type": "bind"
},
{
"destination": "/etc/resolv.conf",
"options": [
"rbind",
"rprivate",
"ro"
],
"source": "/etc/resolv.conf",
"type": "bind"
},
{
"destination": "/etc/hostname",
"options": [
"rbind",
"rprivate",
"ro"
],
"source": "/etc/hostname",
"type": "bind"
},
{
"destination": "/etc/hosts",
"options": [
"rbind",
"rprivate",
"ro"
],
"source": "/etc/hosts",
"type": "bind"
},
{
"destination": "/felix-startup-1.log",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico/node/felix-startup-1.log",
"type": "bind"
},
{
"destination": "/felix-startup-2.log",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico/node/felix-startup-2.log",
"type": "bind"
},
{
"destination": "/etc/envvars",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico/node/envvars",
"type": "bind"
},
{
"destination": "/startup.env",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico/node/startup.env",
"type": "bind"
},
{
"destination": "/etc/service/enabled",
"options": [
"nodev"
],
"source": "tmpfs",
"type": "tmpfs"
},
{
"destination": "/etc/calico/confd/conf.d",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/calico/node/confd/conf.d",
"type": "bind"
},
{
"destination": "/etc/calico/confd/config",
"options": [
"noexec",
"nodev"
],
"source": "tmpfs",
"type": "tmpfs"
},
{
"destination": "/run",
"options": [
"noexec",
"nodev"
],
"source": "tmpfs",
"type": "tmpfs"
},
{
"destination": "/tmp",
"options": [
"nodev"
],
"source": "tmpfs",
"type": "tmpfs"
},
{
"destination": "/run/docker/plugins",
"options": [
"rbind",
"rprivate"
],
"source": "/run/docker/plugins",
"type": "bind"
},
{
"destination": "/var/run/docker.sock",
"options": [
"rbind",
"rprivate"
],
"source": "/var/run/docker.sock",
"type": "bind"
}
],
"ociVersion": "0.6.0-dev",
"platform": {
"arch": "amd64",
"os": "linux"
},
"process": {
"args": [
"/sbin/start_runit"
],
"capabilities": [
"CAP_CHOWN",
"CAP_DAC_OVERRIDE",
"CAP_DAC_READ_SEARCH",
"CAP_FOWNER",
"CAP_FSETID",
"CAP_KILL",
"CAP_SETGID",
"CAP_SETUID",
"CAP_SETPCAP",
"CAP_LINUX_IMMUTABLE",
"CAP_NET_BIND_SERVICE",
"CAP_NET_BROADCAST",
"CAP_NET_ADMIN",
"CAP_NET_RAW",
"CAP_IPC_LOCK",
"CAP_IPC_OWNER",
"CAP_SYS_MODULE",
"CAP_SYS_RAWIO",
"CAP_SYS_CHROOT",
"CAP_SYS_PTRACE",
"CAP_SYS_PACCT",
"CAP_SYS_ADMIN",
"CAP_SYS_BOOT",
"CAP_SYS_NICE",
"CAP_SYS_RESOURCE",
"CAP_SYS_TIME",
"CAP_SYS_TTY_CONFIG",
"CAP_MKNOD",
"CAP_LEASE",
"CAP_AUDIT_WRITE",
"CAP_AUDIT_CONTROL",
"CAP_SETFCAP",
"CAP_MAC_OVERRIDE",
"CAP_MAC_ADMIN",
"CAP_SYSLOG",
"CAP_WAKE_ALARM",
"CAP_BLOCK_SUSPEND",
"CAP_AUDIT_READ"
],
"cwd": "/",
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"HOSTNAME={{HOSTNAME}}",
"ETCD_ENDPOINTS={{ETCD_ENDPOINTS}}",
"ETCD_SCHEME={{ETCD_SCHEME}}",
"ETCD_CA_FILE={{ETCD_CA_FILE}}",
"ETCD_CERT_FILE={{ETCD_CERT_FILE}}",
"ETCD_KEY_FILE={{ETCD_KEY_FILE}}",
"CALICO_NETWORKING_BACKEND={{CALICO_NETWORKING_BACKEND}}",
"CALICO_LIBNETWORK_ENABLED={{CALICO_LIBNETWORK_ENABLED}}",
"NO_DEFAULT_POOLS={{NO_DEFAULT_POOLS}}",
"AS={{AS}}",
"IP={{IP}}",
"IP6={{IP6}}",
"DOCKER_API_VERSION=1.21"
],
"noNewPrivileges": true,
"rlimits": [
{
"hard": 1024,
"soft": 1024,
"type": "RLIMIT_NOFILE"
}
],
"terminal": false,
"user": {}
},
"root": {
"path": "/opt/calico-node",
"readonly": true
}
}
You also generally need a unit file to launch this with (I'm using j2cli to do templating of the config.json):
[Unit]
Description=Calico Network Node
After=docker.service
Requires=docker.service
After=etcd.service
[Service]
# Source static environment for Calico
EnvironmentFile=/etc/calico/calico.env
Environment=HOSTNAME=%H
Environment=CALICO_NETWORKING_BACKEND=bird
Environment=CALICO_LIBNETWORK_ENABLED=true
Environment=NO_DEFAULT_POOLS=true
Environment=AS=
Environment=IP=
Environment=IP6=
# runc requires pre-mount paths exist.
ExecStartPre=/bin/mkdir -p /run/calico/node \
/run/calico/node/confd/conf.d \
/var/log/calico \
/run/docker/plugins
# deal with calico's/conf.d's desire to write and template in /etc
ExecStartPre=/bin/cp -r /opt/calico-node/etc/calico/confd/conf.d \
/run/calico/node/confd
ExecStartPre=/bin/touch /run/calico/node/envvars \
/run/calico/node/startup.env \
/run/calico/node/felix-startup-1.log \
/run/calico/node/felix-startup-2.log
# Template the container config file.
ExecStartPre=/bin/bash -c "/usr/local/bin/j2 -f env /opt/calico-node/config.json.j2 > /run/calico/node/config.json"
ExecStart=/usr/bin/docker-runc --systemd-cgroup start -b /run/calico/node calico-node
Restart=always
RestartSec=10s
[Install]
WantedBy=multi-user.target
Advanced network policy is out-of-date, it uses profiles and tags, not policies and it uses the old calicoctl, not the new golang one.
The v1.5 navbar layout works well to fit our existing documentation into a new, tree-based site. Now that a 1:1 cut has been made, we should move forward with more drastic changes to our layout. This new layout should address the following issue(s) (feel free to comment with more, or open other issues to tackle smaller components of this greater epic):
need to change H2 text size to be smaller in CSS.
Sub-topics are very hard to differentiate with H1 and H2 sizes being very similar.
See this doc for example: https://tigera.github.io/calico/master/reference/architecture/
The stuff in Usage-Logging https://github.com/tigera/calico/blob/master/master/using-calico/troubleshooting/logging.md is container-centric.
For example, in Openstack: there's no calico-node
container, bird is not configured using calicoctl, felix log-level is not set using calicoctl, there's no confd and it doesn't use calico ipam.
Perhaps this info should move to an -Logging document?
The format of the docs in the repo is such that they can be built/hosted by Github pages, if that's what we want.
As it stands, the docs in the gh-master branch of this repo are hosted on tigera.github.io/calico-docs, but we'll presumably want to put the docs in a projectcalico repo, which would move their default location (e.g. projectcalico.github.io/calico).
Github pages supports custom domains (https://help.github.com/articles/using-a-custom-domain-with-github-pages/), so it should be possible to actually have them hosted by github but located somewhere else (e.g. replace the current docs.projectcalico.org).
Basically, we should be able to do what we want - just needs someone to make a decision on what that is.
From @xh3b4sd on September 29, 2016 14:28
As documented on how to stop a calico node it is advised to call calicoctl endpoint remove
. This in fact results into the following.
core@xh3b4sd-k8svm-master ~ $ calicoctl endpoint remove
Usage:
calicoctl endpoint show [--host=<HOSTNAME>] [--orchestrator=<ORCHESTRATOR_ID>]
[--workload=<WORKLOAD_ID>] [--endpoint=<ENDPOINT_ID>] [--detailed]
calicoctl endpoint <ENDPOINT_ID> profile (append|remove|set) [--host=<HOSTNAME>]
[--orchestrator=<ORCHESTRATOR_ID>] [--workload=<WORKLOAD_ID>] [<PROFILES>...]
calicoctl endpoint <ENDPOINT_ID> profile show [--host=<HOSTNAME>]
[--orchestrator=<ORCHESTRATOR_ID>] [--workload=<WORKLOAD_ID>]
I feel like I am doing something fundamentally wrong. Can somebody provide feedback here?
Copied from original issue: projectcalico/calico-containers#1176
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.