Spencer Smith
GitHub
commit
23565ebe62
|
|
@ -24,7 +24,7 @@ explain why.
|
|||
- **Version of Ansible** (`ansible --version`):
|
||||
|
||||
|
||||
**Kargo version (commit) (`git rev-parse --short HEAD`):**
|
||||
**Kubespray version (commit) (`git rev-parse --short HEAD`):**
|
||||
|
||||
|
||||
**Network plugin used**:
|
||||
|
|
|
|||
22
README.md
22
README.md
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Deploy a production ready kubernetes cluster
|
||||
|
||||
If you have questions, join us on the [kubernetes slack](https://slack.k8s.io), channel **#kargo**.
|
||||
If you have questions, join us on the [kubernetes slack](https://slack.k8s.io), channel **#kubespray**.
|
||||
|
||||
- Can be deployed on **AWS, GCE, Azure, OpenStack or Baremetal**
|
||||
- **High available** cluster
|
||||
|
|
@ -13,13 +13,13 @@ If you have questions, join us on the [kubernetes slack](https://slack.k8s.io),
|
|||
|
||||
To deploy the cluster you can use :
|
||||
|
||||
[**kargo-cli**](https://github.com/kubespray/kargo-cli) <br>
|
||||
**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py) <br>
|
||||
[**kubespray-cli**](https://github.com/kubespray/kubespray-cli) <br>
|
||||
**Ansible** usual commands and [**inventory builder**](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py) <br>
|
||||
**vagrant** by simply running `vagrant up` (for tests purposes) <br>
|
||||
|
||||
|
||||
* [Requirements](#requirements)
|
||||
* [Kargo vs ...](docs/comparisons.md)
|
||||
* [Kubespray vs ...](docs/comparisons.md)
|
||||
* [Getting started](docs/getting-started.md)
|
||||
* [Ansible inventory and tags](docs/ansible.md)
|
||||
* [Integration with existing ansible repo](docs/integration.md)
|
||||
|
|
@ -98,22 +98,22 @@ option to leverage built-in cloud provider networking instead.
|
|||
See also [Network checker](docs/netcheck.md).
|
||||
|
||||
## Community docs and resources
|
||||
- [kubernetes.io/docs/getting-started-guides/kargo/](https://kubernetes.io/docs/getting-started-guides/kargo/)
|
||||
- [kargo, monitoring and logging](https://github.com/gregbkr/kubernetes-kargo-logging-monitoring) by @gregbkr
|
||||
- [kubernetes.io/docs/getting-started-guides/kubespray/](https://kubernetes.io/docs/getting-started-guides/kubespray/)
|
||||
- [kubespray, monitoring and logging](https://github.com/gregbkr/kubernetes-kargo-logging-monitoring) by @gregbkr
|
||||
- [Deploy Kubernetes w/ Ansible & Terraform](https://rsmitty.github.io/Terraform-Ansible-Kubernetes/) by @rsmitty
|
||||
- [Deploy a Kubernets Cluster with Kargo (video)](https://www.youtube.com/watch?v=N9q51JgbWu8)
|
||||
- [Deploy a Kubernetes Cluster with Kubespray (video)](https://www.youtube.com/watch?v=N9q51JgbWu8)
|
||||
|
||||
## Tools and projects on top of Kargo
|
||||
## Tools and projects on top of Kubespray
|
||||
- [Digital Rebar](https://github.com/digitalrebar/digitalrebar)
|
||||
- [Kargo-cli](https://github.com/kubespray/kargo-cli)
|
||||
- [Kubespray-cli](https://github.com/kubespray/kubespray-cli)
|
||||
- [Fuel-ccp-installer](https://github.com/openstack/fuel-ccp-installer)
|
||||
- [Terraform Contrib](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/terraform)
|
||||
- [Terraform Contrib](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform)
|
||||
|
||||
## CI Tests
|
||||
|
||||
|
||||
|
||||
[](https://gitlab.com/kargo-ci/kubernetes-incubator__kargo/pipelines) </br>
|
||||
[](https://gitlab.com/kubespray-ci/kubernetes-incubator__kubespray/pipelines) </br>
|
||||
|
||||
CI/end-to-end tests sponsored by Google (GCE), DigitalOcean, [teuto.net](https://teuto.net/) (openstack).
|
||||
See the [test matrix](docs/test_cases.md) for details.
|
||||
|
|
|
|||
18
RELEASE.md
18
RELEASE.md
|
|
@ -1,16 +1,16 @@
|
|||
# Release Process
|
||||
|
||||
The Kargo Project is released on an as-needed basis. The process is as follows:
|
||||
The Kubespray Project is released on an as-needed basis. The process is as follows:
|
||||
|
||||
1. An issue is proposing a new release with a changelog since the last release
|
||||
2. At least on of the [OWNERS](OWNERS) must LGTM this release
|
||||
3. An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION`
|
||||
4. The release issue is closed
|
||||
5. An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kargo $VERSION is released`
|
||||
5. An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] Kubespray $VERSION is released`
|
||||
|
||||
## Major/minor releases, merge freezes and milestones
|
||||
|
||||
* Kargo does not maintain stable branches for releases. Releases are tags, not
|
||||
* Kubespray does not maintain stable branches for releases. Releases are tags, not
|
||||
branches, and there are no backports. Therefore, there is no need for merge
|
||||
freezes as well.
|
||||
|
||||
|
|
@ -20,21 +20,21 @@ The Kargo Project is released on an as-needed basis. The process is as follows:
|
|||
support lifetime, which ends once the milestone closed. Then only a next major
|
||||
or minor release can be done.
|
||||
|
||||
* Kargo major and minor releases are bound to the given ``kube_version`` major/minor
|
||||
* Kubespray major and minor releases are bound to the given ``kube_version`` major/minor
|
||||
version numbers and other components' arbitrary versions, like etcd or network plugins.
|
||||
Older or newer versions are not supported and not tested for the given release.
|
||||
|
||||
* There is no unstable releases and no APIs, thus Kargo doesn't follow
|
||||
* There is no unstable releases and no APIs, thus Kubespray doesn't follow
|
||||
[semver](http://semver.org/). Every version describes only a stable release.
|
||||
Breaking changes, if any introduced by changed defaults or non-contrib ansible roles'
|
||||
playbooks, shall be described in the release notes. Other breaking changes, if any in
|
||||
the contributed addons or bound versions of Kubernetes and other components, are
|
||||
considered out of Kargo scope and are up to the components' teams to deal with and
|
||||
considered out of Kubespray scope and are up to the components' teams to deal with and
|
||||
document.
|
||||
|
||||
* Minor releases can change components' versions, but not the major ``kube_version``.
|
||||
Greater ``kube_version`` requires a new major or minor release. For example, if Kargo v2.0.0
|
||||
Greater ``kube_version`` requires a new major or minor release. For example, if Kubespray v2.0.0
|
||||
is bound to ``kube_version: 1.4.x``, ``calico_version: 0.22.0``, ``etcd_version: v3.0.6``,
|
||||
then Kargo v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1
|
||||
then Kubespray v2.1.0 may be bound to only minor changes to ``kube_version``, like v1.5.1
|
||||
and *any* changes to other components, like etcd v4, or calico 1.2.3.
|
||||
And Kargo v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively.
|
||||
And Kubespray v3.x.x shall be bound to ``kube_version: 2.x.x`` respectively.
|
||||
|
|
|
|||
24
cluster.yml
24
cluster.yml
|
|
@ -2,7 +2,7 @@
|
|||
- hosts: localhost
|
||||
gather_facts: False
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bastion-ssh-config, tags: ["localhost", "bastion"]}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
# fail. bootstrap-os fixes this on these systems, so in later plays it can be enabled.
|
||||
ansible_ssh_pipelining: false
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bootstrap-os, tags: bootstrap-os}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kernel-upgrade, tags: kernel-upgrade, when: kernel_upgrade is defined and kernel_upgrade }
|
||||
- { role: kubernetes/preinstall, tags: preinstall }
|
||||
- { role: docker, tags: docker }
|
||||
|
|
@ -36,38 +36,38 @@
|
|||
- hosts: etcd:k8s-cluster:vault
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults, when: "cert_management == 'vault'" }
|
||||
- { role: kubespray-defaults, when: "cert_management == 'vault'" }
|
||||
- { role: vault, tags: vault, vault_bootstrap: true, when: "cert_management == 'vault'" }
|
||||
|
||||
- hosts: etcd
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: etcd, tags: etcd, etcd_cluster_setup: true }
|
||||
|
||||
- hosts: k8s-cluster
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: etcd, tags: etcd, etcd_cluster_setup: false }
|
||||
|
||||
- hosts: etcd:k8s-cluster:vault
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: vault, tags: vault, when: "cert_management == 'vault'"}
|
||||
|
||||
- hosts: k8s-cluster
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes/node, tags: node }
|
||||
- { role: network_plugin, tags: network }
|
||||
|
||||
- hosts: kube-master
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes/master, tags: master }
|
||||
- { role: kubernetes-apps/network_plugin, tags: network }
|
||||
- { role: kubernetes-apps/policy_controller, tags: policy-controller }
|
||||
|
|
@ -75,18 +75,18 @@
|
|||
- hosts: calico-rr
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: network_plugin/calico/rr, tags: network }
|
||||
|
||||
- hosts: k8s-cluster
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: dnsmasq, when: "dns_mode == 'dnsmasq_kubedns'", tags: dnsmasq }
|
||||
- { role: kubernetes/preinstall, when: "dns_mode != 'none' and resolvconf_mode == 'host_resolvconf'", tags: resolvconf }
|
||||
|
||||
- hosts: kube-master[0]
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes-apps, tags: apps }
|
||||
|
|
|
|||
|
|
@ -33,10 +33,10 @@ class SearchEC2Tags(object):
|
|||
hosts = {}
|
||||
hosts['_meta'] = { 'hostvars': {} }
|
||||
|
||||
##Search ec2 three times to find nodes of each group type. Relies on kargo-role key/value.
|
||||
##Search ec2 three times to find nodes of each group type. Relies on kubespray-role key/value.
|
||||
for group in ["kube-master", "kube-node", "etcd"]:
|
||||
hosts[group] = []
|
||||
tag_key = "kargo-role"
|
||||
tag_key = "kubespray-role"
|
||||
tag_value = ["*"+group+"*"]
|
||||
region = os.environ['REGION']
|
||||
|
||||
|
|
@ -5,7 +5,7 @@ Provision the base infrastructure for a Kubernetes cluster by using [Azure Resou
|
|||
## Status
|
||||
|
||||
This will provision the base infrastructure (vnet, vms, nics, ips, ...) needed for Kubernetes in Azure into the specified
|
||||
Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kargo of course).
|
||||
Resource Group. It will not install Kubernetes itself, this has to be done in a later step by yourself (using kubespray of course).
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ $ ./clear-rg.sh <resource_group_name>
|
|||
**WARNING** this really deletes everything from your resource group, including everything that was later created by you!
|
||||
|
||||
|
||||
## Generating an inventory for kargo
|
||||
## Generating an inventory for kubespray
|
||||
|
||||
After you have applied the templates, you can generate an inventory with this call:
|
||||
|
||||
|
|
@ -55,10 +55,10 @@ After you have applied the templates, you can generate an inventory with this ca
|
|||
$ ./generate-inventory.sh <resource_group_name>
|
||||
```
|
||||
|
||||
It will create the file ./inventory which can then be used with kargo, e.g.:
|
||||
It will create the file ./inventory which can then be used with kubespray, e.g.:
|
||||
|
||||
```shell
|
||||
$ cd kargo-root-dir
|
||||
$ cd kubespray-root-dir
|
||||
$ ansible-playbook -i contrib/azurerm/inventory -u devops --become -e "@inventory/group_vars/all.yml" cluster.yml
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ HOST_PREFIX = os.environ.get("HOST_PREFIX", "node")
|
|||
# Configurable as shell vars end
|
||||
|
||||
|
||||
class KargoInventory(object):
|
||||
class KubesprayInventory(object):
|
||||
|
||||
def __init__(self, changed_hosts=None, config_file=None):
|
||||
self.config = configparser.ConfigParser(allow_no_value=True,
|
||||
|
|
@ -337,7 +337,7 @@ MASSIVE_SCALE_THRESHOLD Separate K8s master and ETCD if # of nodes >= 200
|
|||
def main(argv=None):
|
||||
if not argv:
|
||||
argv = sys.argv[1:]
|
||||
KargoInventory(argv, CONFIG_FILE)
|
||||
KubesprayInventory(argv, CONFIG_FILE)
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
[metadata]
|
||||
name = kargo-inventory-builder
|
||||
name = kubespray-inventory-builder
|
||||
version = 0.1
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ class TestInventory(unittest.TestCase):
|
|||
sys_mock.exit = mock.Mock()
|
||||
super(TestInventory, self).setUp()
|
||||
self.data = ['10.90.3.2', '10.90.3.3', '10.90.3.4']
|
||||
self.inv = inventory.KargoInventory()
|
||||
self.inv = inventory.KubesprayInventory()
|
||||
|
||||
def test_get_ip_from_opts(self):
|
||||
optstring = "ansible_host=10.90.3.2 ip=10.90.3.2"
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Kargo on KVM Virtual Machines hypervisor preparation
|
||||
# Kubespray on KVM Virtual Machines hypervisor preparation
|
||||
|
||||
A simple playbook to ensure your system has the right settings to enable Kargo
|
||||
A simple playbook to ensure your system has the right settings to enable Kubespray
|
||||
deployment on VMs.
|
||||
|
||||
This playbook does not create Virtual Machines, nor does it run Kargo itself.
|
||||
This playbook does not create Virtual Machines, nor does it run Kubespray itself.
|
||||
|
||||
### User creation
|
||||
|
||||
If you want to create a user for running Kargo deployment, you should specify
|
||||
If you want to create a user for running Kubespray deployment, you should specify
|
||||
both `k8s_deployment_user` and `k8s_deployment_user_pkey_path`.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
#k8s_deployment_user: kargo
|
||||
#k8s_deployment_user: kubespray
|
||||
#k8s_deployment_user_pkey_path: /tmp/ssh_rsa
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@
|
|||
line: 'br_netfilter'
|
||||
when: br_netfilter is defined and ansible_os_family == 'Debian'
|
||||
|
||||
- name: Add br_netfilter into /etc/modules-load.d/kargo.conf
|
||||
- name: Add br_netfilter into /etc/modules-load.d/kubespray.conf
|
||||
copy:
|
||||
dest: /etc/modules-load.d/kargo.conf
|
||||
dest: /etc/modules-load.d/kubespray.conf
|
||||
content: |-
|
||||
### This file is managed by Ansible
|
||||
br-netfilter
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Deploying a Kargo Kubernetes Cluster with GlusterFS
|
||||
# Deploying a Kubespray Kubernetes Cluster with GlusterFS
|
||||
|
||||
You can either deploy using Ansible on its own by supplying your own inventory file or by using Terraform to create the VMs and then providing a dynamic inventory to Ansible. The following two sections are self-contained, you don't need to go through one to use the other. So, if you want to provision with Terraform, you can skip the **Using an Ansible inventory** section, and if you want to provision with a pre-built ansible inventory, you can neglect the **Using Terraform and Ansible** section.
|
||||
|
||||
|
|
@ -6,7 +6,7 @@ You can either deploy using Ansible on its own by supplying your own inventory f
|
|||
|
||||
In the same directory of this ReadMe file you should find a file named `inventory.example` which contains an example setup. Please note that, additionally to the Kubernetes nodes/masters, we define a set of machines for GlusterFS and we add them to the group `[gfs-cluster]`, which in turn is added to the larger `[network-storage]` group as a child group.
|
||||
|
||||
Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kargo root folder, and execute (supposing that the machines are all using ubuntu):
|
||||
Change that file to reflect your local setup (adding more machines or removing them and setting the adequate ip numbers), and save it to `inventory/k8s_gfs_inventory`. Make sure that the settings on `inventory/group_vars/all.yml` make sense with your deployment. Then execute change to the kubespray root folder, and execute (supposing that the machines are all using ubuntu):
|
||||
|
||||
```
|
||||
ansible-playbook -b --become-user=root -i inventory/k8s_gfs_inventory --user=ubuntu ./cluster.yml
|
||||
|
|
@ -28,7 +28,7 @@ k8s-master-node-2 ansible_ssh_host=192.168.0.146 ip=192.168.0.146 ansible_ssh_us
|
|||
|
||||
## Using Terraform and Ansible
|
||||
|
||||
First step is to fill in a `my-kargo-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like:
|
||||
First step is to fill in a `my-kubespray-gluster-cluster.tfvars` file with the specification desired for your cluster. An example with all required variables would look like:
|
||||
|
||||
```
|
||||
cluster_name = "cluster1"
|
||||
|
|
@ -65,15 +65,15 @@ $ echo Setting up Terraform creds && \
|
|||
export TF_VAR_auth_url=${OS_AUTH_URL}
|
||||
```
|
||||
|
||||
Then, standing on the kargo directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster:
|
||||
Then, standing on the kubespray directory (root base of the Git checkout), issue the following terraform command to create the VMs for the cluster:
|
||||
|
||||
```
|
||||
terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack
|
||||
terraform apply -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack
|
||||
```
|
||||
|
||||
This will create both your Kubernetes and Gluster VMs. Make sure that the ansible file `contrib/terraform/openstack/group_vars/all.yml` includes any ansible variable that you want to setup (like, for instance, the type of machine for bootstrapping).
|
||||
|
||||
Then, provision your Kubernetes (Kargo) cluster with the following ansible call:
|
||||
Then, provision your Kubernetes (kubespray) cluster with the following ansible call:
|
||||
|
||||
```
|
||||
ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./cluster.yml
|
||||
|
|
@ -88,5 +88,5 @@ ansible-playbook -b --become-user=root -i contrib/terraform/openstack/hosts ./co
|
|||
If you need to destroy the cluster, you can run:
|
||||
|
||||
```
|
||||
terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kargo-gluster-cluster.tfvars contrib/terraform/openstack
|
||||
terraform destroy -state=contrib/terraform/openstack/terraform.tfstate -var-file=my-kubespray-gluster-cluster.tfvars contrib/terraform/openstack
|
||||
```
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ export AWS_DEFAULT_REGION="zzz"
|
|||
|
||||
- Terraform automatically creates an Ansible Inventory file called `hosts` with the created infrastructure in the directory `inventory`
|
||||
|
||||
- Once the infrastructure is created, you can run the kargo playbooks and supply inventory/hosts with the `-i` flag.
|
||||
- Once the infrastructure is created, you can run the kubespray playbooks and supply inventory/hosts with the `-i` flag.
|
||||
|
||||
**Troubleshooting**
|
||||
|
||||
|
|
@ -54,4 +54,4 @@ It could happen that Terraform doesnt create an Ansible Inventory file automatic
|
|||
|
||||
Pictured is an AWS Infrastructure created with this Terraform project distributed over two Availability Zones.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ resource "aws_instance" "k8s-worker" {
|
|||
|
||||
|
||||
/*
|
||||
* Create Kargo Inventory File
|
||||
* Create Kubespray Inventory File
|
||||
*
|
||||
*/
|
||||
data "template_file" "inventory" {
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 114 KiB |
|
|
@ -75,25 +75,25 @@ According to the [ansible docs](http://docs.ansible.com/ansible/playbooks_variab
|
|||
those cannot be overriden from the group vars. In order to override, one should use
|
||||
the `-e ` runtime flags (most simple way) or other layers described in the docs.
|
||||
|
||||
Kargo uses only a few layers to override things (or expect them to
|
||||
Kubespray uses only a few layers to override things (or expect them to
|
||||
be overriden for roles):
|
||||
|
||||
Layer | Comment
|
||||
------|--------
|
||||
**role defaults** | provides best UX to override things for Kargo deployments
|
||||
**role defaults** | provides best UX to override things for Kubespray deployments
|
||||
inventory vars | Unused
|
||||
**inventory group_vars** | Expects users to use ``all.yml``,``k8s-cluster.yml`` etc. to override things
|
||||
inventory host_vars | Unused
|
||||
playbook group_vars | Unuses
|
||||
playbook host_vars | Unused
|
||||
**host facts** | Kargo overrides for internal roles' logic, like state flags
|
||||
**host facts** | Kubespray overrides for internal roles' logic, like state flags
|
||||
play vars | Unused
|
||||
play vars_prompt | Unused
|
||||
play vars_files | Unused
|
||||
registered vars | Unused
|
||||
set_facts | Kargo overrides those, for some places
|
||||
set_facts | Kubespray overrides those, for some places
|
||||
**role and include vars** | Provides bad UX to override things! Use extra vars to enforce
|
||||
block vars (only for tasks in block) | Kargo overrides for internal roles' logic
|
||||
block vars (only for tasks in block) | Kubespray overrides for internal roles' logic
|
||||
task vars (only for the task) | Unused for roles, but only for helper scripts
|
||||
**extra vars** (always win precedence) | override with ``ansible-playbook -e @foo.yml``
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ AWS
|
|||
|
||||
To deploy kubespray on [AWS](https://aws.amazon.com/) uncomment the `cloud_provider` option in `group_vars/all.yml` and set it to `'aws'`.
|
||||
|
||||
Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kargo/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role.
|
||||
Prior to creating your instances, you **must** ensure that you have created IAM roles and policies for both "kubernetes-master" and "kubernetes-node". You can find the IAM policies [here](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/aws_iam/). See the [IAM Documentation](https://aws.amazon.com/documentation/iam/) if guidance is needed on how to set these up. When you bring your instances online, associate them with the respective IAM role. Nodes that are only to be used for Etcd do not need a role.
|
||||
|
||||
The next step is to make sure the hostnames in your `inventory` file are identical to your internal hostnames in AWS. This may look something like `ip-111-222-333-444.us-west-2.compute.internal`. You can then specify how Ansible connects to these instances with `ansible_ssh_host` and `ansible_ssh_user`.
|
||||
|
||||
|
|
@ -45,12 +45,12 @@ This will produce an inventory that is passed into Ansible that looks like the f
|
|||
|
||||
Guide:
|
||||
- Create instances in AWS as needed.
|
||||
- Either during or after creation, add tags to the instances with a key of `kargo-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd`
|
||||
- Copy the `kargo-aws-inventory.py` script from `kargo/contrib/aws_inventory` to the `kargo/inventory` directory.
|
||||
- Either during or after creation, add tags to the instances with a key of `kubespray-role` and a value of `kube-master`, `etcd`, or `kube-node`. You can also share roles like `kube-master, etcd`
|
||||
- Copy the `kubespray-aws-inventory.py` script from `kubespray/contrib/aws_inventory` to the `kubespray/inventory` directory.
|
||||
- Set the following AWS credentials and info as environment variables in your terminal:
|
||||
```
|
||||
export AWS_ACCESS_KEY_ID="xxxxx"
|
||||
export AWS_SECRET_ACCESS_KEY="yyyyy"
|
||||
export REGION="us-east-2"
|
||||
```
|
||||
- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kargo-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml`
|
||||
- We will now create our cluster. There will be either one or two small changes. The first is that we will specify `-i inventory/kubespray-aws-inventory.py` as our inventory script. The other is conditional. If your AWS instances are public facing, you can set the `VPC_VISIBILITY` variable to `public` and that will result in public IP and DNS names being passed into the inventory. This causes your cluster.yml command to look like `VPC_VISIBILITY="public" ansible-playbook ... cluster.yml`
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ You need to edit your inventory and add:
|
|||
* `cluster_id` by route reflector node/group (see details
|
||||
[here](https://hub.docker.com/r/calico/routereflector/))
|
||||
|
||||
Here's an example of Kargo inventory with route reflectors:
|
||||
Here's an example of Kubespray inventory with route reflectors:
|
||||
|
||||
```
|
||||
[all]
|
||||
|
|
@ -145,11 +145,11 @@ cluster_id="1.0.0.1"
|
|||
The inventory above will deploy the following topology assuming that calico's
|
||||
`global_as_num` is set to `65400`:
|
||||
|
||||
|
||||
|
||||
|
||||
##### Optional : Define default endpoint to host action
|
||||
|
||||
By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kargo) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped.
|
||||
By default Calico blocks traffic from endpoints to the host itself by using an iptables DROP action. When using it in kubernetes the action has to be changed to RETURN (default in kubespray) or ACCEPT (see https://github.com/projectcalico/felix/issues/660 and https://github.com/projectcalico/calicoctl/issues/1389). Otherwise all network packets from pods (with hostNetwork=False) to services endpoints (with hostNetwork=True) withing the same node are dropped.
|
||||
|
||||
|
||||
To re-define default action please set the following variable in your inventory:
|
||||
|
|
|
|||
|
|
@ -3,17 +3,17 @@ Cloud providers
|
|||
|
||||
#### Provisioning
|
||||
|
||||
You can use kargo-cli to start new instances on cloud providers
|
||||
You can use kubespray-cli to start new instances on cloud providers
|
||||
here's an example
|
||||
```
|
||||
kargo [aws|gce] --nodes 2 --etcd 3 --cluster-name test-smana
|
||||
kubespray [aws|gce] --nodes 2 --etcd 3 --cluster-name test-smana
|
||||
```
|
||||
|
||||
#### Deploy kubernetes
|
||||
|
||||
With kargo-cli
|
||||
With kubespray-cli
|
||||
```
|
||||
kargo deploy [--aws|--gce] -u admin
|
||||
kubespray deploy [--aws|--gce] -u admin
|
||||
```
|
||||
|
||||
Or ansible-playbook command
|
||||
|
|
|
|||
|
|
@ -1,25 +1,25 @@
|
|||
Kargo vs [Kops](https://github.com/kubernetes/kops)
|
||||
Kubespray vs [Kops](https://github.com/kubernetes/kops)
|
||||
---------------
|
||||
|
||||
Kargo runs on bare metal and most clouds, using Ansible as its substrate for
|
||||
Kubespray runs on bare metal and most clouds, using Ansible as its substrate for
|
||||
provisioning and orchestration. Kops performs the provisioning and orchestration
|
||||
itself, and as such is less flexible in deployment platforms. For people with
|
||||
familiarity with Ansible, existing Ansible deployments or the desire to run a
|
||||
Kubernetes cluster across multiple platforms, Kargo is a good choice. Kops,
|
||||
Kubernetes cluster across multiple platforms, Kubespray is a good choice. Kops,
|
||||
however, is more tightly integrated with the unique features of the clouds it
|
||||
supports so it could be a better choice if you know that you will only be using
|
||||
one platform for the foreseeable future.
|
||||
|
||||
Kargo vs [Kubeadm](https://github.com/kubernetes/kubeadm)
|
||||
Kubespray vs [Kubeadm](https://github.com/kubernetes/kubeadm)
|
||||
------------------
|
||||
|
||||
Kubeadm provides domain Knowledge of Kubernetes clusters' life cycle
|
||||
management, including self-hosted layouts, dynamic discovery services and so
|
||||
on. Had it belong to the new [operators world](https://coreos.com/blog/introducing-operators.html),
|
||||
it would've likely been named a "Kubernetes cluster operator". Kargo however,
|
||||
it would've likely been named a "Kubernetes cluster operator". Kubespray however,
|
||||
does generic configuration management tasks from the "OS operators" ansible
|
||||
world, plus some initial K8s clustering (with networking plugins included) and
|
||||
control plane bootstrapping. Kargo [strives](https://github.com/kubernetes-incubator/kargo/issues/553)
|
||||
control plane bootstrapping. Kubespray [strives](https://github.com/kubernetes-incubator/kubespray/issues/553)
|
||||
to adopt kubeadm as a tool in order to consume life cycle management domain
|
||||
knowledge from it and offload generic OS configuration things from it, which
|
||||
hopefully benefits both sides.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
CoreOS bootstrap
|
||||
===============
|
||||
|
||||
Example with **kargo-cli**:
|
||||
Example with **kubespray-cli**:
|
||||
|
||||
```
|
||||
kargo deploy --gce --coreos
|
||||
kubespray deploy --gce --coreos
|
||||
```
|
||||
|
||||
Or with Ansible:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
K8s DNS stack by Kargo
|
||||
K8s DNS stack by Kubespray
|
||||
======================
|
||||
|
||||
For K8s cluster nodes, kargo configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/)
|
||||
For K8s cluster nodes, Kubespray configures a [Kubernetes DNS](http://kubernetes.io/docs/admin/dns/)
|
||||
[cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md)
|
||||
to serve as an authoritative DNS server for a given ``dns_domain`` and its
|
||||
``svc, default.svc`` default subdomains (a total of ``ndots: 5`` max levels).
|
||||
|
|
@ -44,13 +44,13 @@ DNS servers to be added *after* the cluster DNS. Used by all ``resolvconf_mode``
|
|||
DNS servers in early cluster deployment when no cluster DNS is available yet. These are also added as upstream
|
||||
DNS servers used by ``dnsmasq`` (when deployed with ``dns_mode: dnsmasq_kubedns``).
|
||||
|
||||
DNS modes supported by kargo
|
||||
DNS modes supported by Kubespray
|
||||
============================
|
||||
|
||||
You can modify how kargo sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``.
|
||||
You can modify how Kubespray sets up DNS for your cluster with the variables ``dns_mode`` and ``resolvconf_mode``.
|
||||
|
||||
## dns_mode
|
||||
``dns_mode`` configures how kargo will setup cluster DNS. There are three modes available:
|
||||
``dns_mode`` configures how Kubespray will setup cluster DNS. There are three modes available:
|
||||
|
||||
#### dnsmasq_kubedns (default)
|
||||
This installs an additional dnsmasq DaemonSet which gives more flexibility and lifts some
|
||||
|
|
@ -67,7 +67,7 @@ This does not install any of dnsmasq and kubedns/skydns. This basically disables
|
|||
leaves you with a non functional cluster.
|
||||
|
||||
## resolvconf_mode
|
||||
``resolvconf_mode`` configures how kargo will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers.
|
||||
``resolvconf_mode`` configures how Kubespray will setup DNS for ``hostNetwork: true`` PODs and non-k8s containers.
|
||||
There are three modes available:
|
||||
|
||||
#### docker_dns (default)
|
||||
|
|
@ -100,7 +100,7 @@ used as a backup nameserver. After cluster DNS is running, all queries will be a
|
|||
servers, which in turn will forward queries to the system nameserver if required.
|
||||
|
||||
#### host_resolvconf
|
||||
This activates the classic kargo behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient
|
||||
This activates the classic Kubespray behaviour that modifies the hosts ``/etc/resolv.conf`` file and dhclient
|
||||
configuration to point to the cluster dns server (either dnsmasq or kubedns, depending on dns_mode).
|
||||
|
||||
As cluster DNS is not available on early deployment stage, this mode is split into 2 stages. In the first
|
||||
|
|
@ -120,7 +120,7 @@ cluster service names.
|
|||
Limitations
|
||||
-----------
|
||||
|
||||
* Kargo has yet ways to configure Kubedns addon to forward requests SkyDns can
|
||||
* Kubespray has yet ways to configure Kubedns addon to forward requests SkyDns can
|
||||
not answer with authority to arbitrary recursive resolvers. This task is left
|
||||
for future. See [official SkyDns docs](https://github.com/skynetservices/skydns)
|
||||
for details.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Downloading binaries and containers
|
||||
===================================
|
||||
|
||||
Kargo supports several download/upload modes. The default is:
|
||||
Kubespray supports several download/upload modes. The default is:
|
||||
|
||||
* Each node downloads binaries and container images on its own, which is
|
||||
``download_run_once: False``.
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
|
|
@ -1,21 +1,21 @@
|
|||
Getting started
|
||||
===============
|
||||
|
||||
The easiest way to run the deployement is to use the **kargo-cli** tool.
|
||||
A complete documentation can be found in its [github repository](https://github.com/kubespray/kargo-cli).
|
||||
The easiest way to run the deployement is to use the **kubespray-cli** tool.
|
||||
A complete documentation can be found in its [github repository](https://github.com/kubespray/kubespray-cli).
|
||||
|
||||
Here is a simple example on AWS:
|
||||
|
||||
* Create instances and generate the inventory
|
||||
|
||||
```
|
||||
kargo aws --instances 3
|
||||
kubespray aws --instances 3
|
||||
```
|
||||
|
||||
* Run the deployment
|
||||
|
||||
```
|
||||
kargo deploy --aws -u centos -n calico
|
||||
kubespray deploy --aws -u centos -n calico
|
||||
```
|
||||
|
||||
Building your own inventory
|
||||
|
|
@ -23,12 +23,12 @@ Building your own inventory
|
|||
|
||||
Ansible inventory can be stored in 3 formats: YAML, JSON, or INI-like. There is
|
||||
an example inventory located
|
||||
[here](https://github.com/kubernetes-incubator/kargo/blob/master/inventory/inventory.example).
|
||||
[here](https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/inventory.example).
|
||||
|
||||
You can use an
|
||||
[inventory generator](https://github.com/kubernetes-incubator/kargo/blob/master/contrib/inventory_builder/inventory.py)
|
||||
[inventory generator](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py)
|
||||
to create or modify an Ansible inventory. Currently, it is limited in
|
||||
functionality and is only use for making a basic Kargo cluster, but it does
|
||||
functionality and is only use for making a basic Kubespray cluster, but it does
|
||||
support creating large clusters. It now supports
|
||||
separated ETCD and Kubernetes master roles from node role if the size exceeds a
|
||||
certain threshold. Run inventory.py help for more information.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Kube-apiserver
|
|||
--------------
|
||||
|
||||
K8s components require a loadbalancer to access the apiservers via a reverse
|
||||
proxy. Kargo includes support for an nginx-based proxy that resides on each
|
||||
proxy. Kubespray includes support for an nginx-based proxy that resides on each
|
||||
non-master Kubernetes node. This is referred to as localhost loadbalancing. It
|
||||
is less efficient than a dedicated load balancer because it creates extra
|
||||
health checks on the Kubernetes apiserver, but is more practical for scenarios
|
||||
|
|
@ -30,12 +30,12 @@ where an external LB or virtual IP management is inconvenient. This option is
|
|||
configured by the variable `loadbalancer_apiserver_localhost` (defaults to `True`).
|
||||
You may also define the port the local internal loadbalancer users by changing,
|
||||
`nginx_kube_apiserver_port`. This defaults to the value of `kube_apiserver_port`.
|
||||
It is also import to note that Kargo will only configure kubelet and kube-proxy
|
||||
It is also import to note that Kubespray will only configure kubelet and kube-proxy
|
||||
on non-master nodes to use the local internal loadbalancer.
|
||||
|
||||
If you choose to NOT use the local internal loadbalancer, you will need to configure
|
||||
your own loadbalancer to achieve HA. Note that deploying a loadbalancer is up to
|
||||
a user and is not covered by ansible roles in Kargo. By default, it only configures
|
||||
a user and is not covered by ansible roles in Kubespray. By default, it only configures
|
||||
a non-HA endpoint, which points to the `access_ip` or IP address of the first server
|
||||
node in the `kube-master` group. It can also configure clients to use endpoints
|
||||
for a given loadbalancer type. The following diagram shows how traffic to the
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Network Checker Application
|
||||
===========================
|
||||
|
||||
With the ``deploy_netchecker`` var enabled (defaults to false), Kargo deploys a
|
||||
With the ``deploy_netchecker`` var enabled (defaults to false), Kubespray deploys a
|
||||
Network Checker Application from the 3rd side `l23network/k8s-netchecker` docker
|
||||
images. It consists of the server and agents trying to reach the server by usual
|
||||
for Kubernetes applications network connectivity meanings. Therefore, this
|
||||
|
|
@ -17,7 +17,7 @@ any of the cluster nodes:
|
|||
```
|
||||
curl http://localhost:31081/api/v1/connectivity_check
|
||||
```
|
||||
Note that Kargo does not invoke the check but only deploys the application, if
|
||||
Note that Kubespray does not invoke the check but only deploys the application, if
|
||||
requested.
|
||||
|
||||
There are related application specifc variables:
|
||||
|
|
|
|||
|
|
@ -1,23 +1,23 @@
|
|||
Kargo's roadmap
|
||||
Kubespray's roadmap
|
||||
=================
|
||||
|
||||
### Kubeadm
|
||||
- Propose kubeadm as an option in order to setup the kubernetes cluster.
|
||||
That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kargo/issues/553)
|
||||
That would probably improve deployment speed and certs management [#553](https://github.com/kubespray/kubespray/issues/553)
|
||||
|
||||
### Self deployment (pull-mode) [#320](https://github.com/kubespray/kargo/issues/320)
|
||||
### Self deployment (pull-mode) [#320](https://github.com/kubespray/kubespray/issues/320)
|
||||
- the playbook would install and configure docker/rkt and the etcd cluster
|
||||
- the following data would be inserted into etcd: certs,tokens,users,inventory,group_vars.
|
||||
- a "kubespray" container would be deployed (kargo-cli, ansible-playbook, kpm)
|
||||
- a "kubespray" container would be deployed (kubespray-cli, ansible-playbook, kpm)
|
||||
- to be discussed, a way to provide the inventory
|
||||
- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kargo/issues/321)
|
||||
- **self deployment** of the node from inside a container [#321](https://github.com/kubespray/kubespray/issues/321)
|
||||
|
||||
### Provisionning and cloud providers
|
||||
- [ ] Terraform to provision instances on **GCE, AWS, Openstack, Digital Ocean, Azure**
|
||||
- [ ] On AWS autoscaling, multi AZ
|
||||
- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kargo/issues/297)
|
||||
- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kargo/issues/280)
|
||||
- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kargo/issues/234)
|
||||
- [ ] On Azure autoscaling, create loadbalancer [#297](https://github.com/kubespray/kubespray/issues/297)
|
||||
- [ ] On GCE be able to create a loadbalancer automatically (IAM ?) [#280](https://github.com/kubespray/kubespray/issues/280)
|
||||
- [x] **TLS boostrap** support for kubelet [#234](https://github.com/kubespray/kubespray/issues/234)
|
||||
(related issues: https://github.com/kubernetes/kubernetes/pull/20439 <br>
|
||||
https://github.com/kubernetes/kubernetes/issues/18112)
|
||||
|
||||
|
|
@ -37,14 +37,14 @@ That would probably improve deployment speed and certs management [#553](https:/
|
|||
- [ ] test scale up cluster: +1 etcd, +1 master, +1 node
|
||||
|
||||
### Lifecycle
|
||||
- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kargo/issues/553)
|
||||
- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kargo/issues/154)
|
||||
- [ ] Adopt the kubeadm tool by delegating CM tasks it is capable to accomplish well [#553](https://github.com/kubespray/kubespray/issues/553)
|
||||
- [x] Drain worker node when upgrading k8s components in a worker node. [#154](https://github.com/kubespray/kubespray/issues/154)
|
||||
- [ ] Drain worker node when shutting down/deleting an instance
|
||||
- [ ] Upgrade granularity: select components to upgrade and skip others
|
||||
|
||||
### Networking
|
||||
- [ ] romana.io support [#160](https://github.com/kubespray/kargo/issues/160)
|
||||
- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kargo/issues/159)
|
||||
- [ ] romana.io support [#160](https://github.com/kubespray/kubespray/issues/160)
|
||||
- [ ] Configure network policy for Calico. [#159](https://github.com/kubespray/kubespray/issues/159)
|
||||
- [ ] Opencontrail
|
||||
- [x] Canal
|
||||
- [x] Cloud Provider native networking (instead of our network plugins)
|
||||
|
|
@ -53,14 +53,14 @@ That would probably improve deployment speed and certs management [#553](https:/
|
|||
- (to be discussed) option to set a loadbalancer for the apiservers like ucarp/packemaker/keepalived
|
||||
While waiting for the issue [kubernetes/kubernetes#18174](https://github.com/kubernetes/kubernetes/issues/18174) to be fixed.
|
||||
|
||||
### Kargo-cli
|
||||
### Kubespray-cli
|
||||
- Delete instances
|
||||
- `kargo vagrant` to setup a test cluster locally
|
||||
- `kargo azure` for Microsoft Azure support
|
||||
- `kubespray vagrant` to setup a test cluster locally
|
||||
- `kubespray azure` for Microsoft Azure support
|
||||
- switch to Terraform instead of Ansible for provisionning
|
||||
- update $HOME/.kube/config when a cluster is deployed. Optionally switch to this context
|
||||
|
||||
### Kargo API
|
||||
### Kubespray API
|
||||
- Perform all actions through an **API**
|
||||
- Store inventories / configurations of mulltiple clusters
|
||||
- make sure that state of cluster is completely saved in no more than one config file beyond hosts inventory
|
||||
|
|
@ -87,8 +87,8 @@ Include optionals deployments to init the cluster:
|
|||
### Others
|
||||
- remove nodes (adding is already supported)
|
||||
- being able to choose any k8s version (almost done)
|
||||
- **rkt** support [#59](https://github.com/kubespray/kargo/issues/59)
|
||||
- **rkt** support [#59](https://github.com/kubespray/kubespray/issues/59)
|
||||
- Review documentation (split in categories)
|
||||
- **consul** -> if officialy supported by k8s
|
||||
- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kargo/issues/312)
|
||||
- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kargo/issues/329)
|
||||
- flex volumes options (e.g. **torrus** support) [#312](https://github.com/kubespray/kubespray/issues/312)
|
||||
- Clusters federation option (aka **ubernetes**) [#329](https://github.com/kubespray/kubespray/issues/329)
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Upgrading Kubernetes in Kargo
|
||||
Upgrading Kubernetes in Kubespray
|
||||
=============================
|
||||
|
||||
#### Description
|
||||
|
||||
Kargo handles upgrades the same way it handles initial deployment. That is to
|
||||
Kubespray handles upgrades the same way it handles initial deployment. That is to
|
||||
say that each component is laid down in a fixed order. You should be able to
|
||||
upgrade from Kargo tag 2.0 up to the current master without difficulty. You can
|
||||
upgrade from Kubespray tag 2.0 up to the current master without difficulty. You can
|
||||
also individually control versions of components by explicitly defining their
|
||||
versions. Here are all version vars for each component:
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.6
|
|||
|
||||
#### Graceful upgrade
|
||||
|
||||
Kargo also supports cordon, drain and uncordoning of nodes when performing
|
||||
Kubespray also supports cordon, drain and uncordoning of nodes when performing
|
||||
a cluster upgrade. There is a separate playbook used for this purpose. It is
|
||||
important to note that upgrade-cluster.yml can only be used for upgrading an
|
||||
existing cluster. That means there must be at least 1 kube-master already
|
||||
|
|
|
|||
16
docs/vars.md
16
docs/vars.md
|
|
@ -1,4 +1,4 @@
|
|||
Configurable Parameters in Kargo
|
||||
Configurable Parameters in Kubespray
|
||||
================================
|
||||
|
||||
#### Generic Ansible variables
|
||||
|
|
@ -12,7 +12,7 @@ Some variables of note include:
|
|||
* *ansible_default_ipv4.address*: IP address Ansible automatically chooses.
|
||||
Generated based on the output from the command ``ip -4 route get 8.8.8.8``
|
||||
|
||||
#### Common vars that are used in Kargo
|
||||
#### Common vars that are used in Kubespray
|
||||
|
||||
* *calico_version* - Specify version of Calico to use
|
||||
* *calico_cni_version* - Specify version of Calico CNI plugin to use
|
||||
|
|
@ -35,16 +35,16 @@ Some variables of note include:
|
|||
* *access_ip* - IP for other hosts to use to connect to. Often required when
|
||||
deploying from a cloud, such as OpenStack or GCE and you have separate
|
||||
public/floating and private IPs.
|
||||
* *ansible_default_ipv4.address* - Not Kargo-specific, but it is used if ip
|
||||
* *ansible_default_ipv4.address* - Not Kubespray-specific, but it is used if ip
|
||||
and access_ip are undefined
|
||||
* *loadbalancer_apiserver* - If defined, all hosts will connect to this
|
||||
address instead of localhost for kube-masters and kube-master[0] for
|
||||
kube-nodes. See more details in the
|
||||
[HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md).
|
||||
[HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md).
|
||||
* *loadbalancer_apiserver_localhost* - makes all hosts to connect to
|
||||
the apiserver internally load balanced endpoint. Mutual exclusive to the
|
||||
`loadbalancer_apiserver`. See more details in the
|
||||
[HA guide](https://github.com/kubernetes-incubator/kargo/blob/master/docs/ha-mode.md).
|
||||
[HA guide](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md).
|
||||
|
||||
#### Cluster variables
|
||||
|
||||
|
|
@ -79,13 +79,13 @@ other settings from your existing /etc/resolv.conf are lost. Set the following
|
|||
variables to match your requirements.
|
||||
|
||||
* *upstream_dns_servers* - Array of upstream DNS servers configured on host in
|
||||
addition to Kargo deployed DNS
|
||||
addition to Kubespray deployed DNS
|
||||
* *nameservers* - Array of DNS servers configured for use in dnsmasq
|
||||
* *searchdomains* - Array of up to 4 search domains
|
||||
* *skip_dnsmasq* - Don't set up dnsmasq (use only KubeDNS)
|
||||
|
||||
For more information, see [DNS
|
||||
Stack](https://github.com/kubernetes-incubator/kargo/blob/master/docs/dns-stack.md).
|
||||
Stack](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md).
|
||||
|
||||
#### Other service variables
|
||||
|
||||
|
|
@ -114,5 +114,5 @@ The possible vars are:
|
|||
|
||||
#### User accounts
|
||||
|
||||
Kargo sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their
|
||||
Kubespray sets up two Kubernetes accounts by default: ``root`` and ``kube``. Their
|
||||
passwords default to changeme. You can set this by changing ``kube_api_pwd``.
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ vault group.
|
|||
It is *highly* recommended that these secrets are removed from the servers after
|
||||
your cluster has been deployed, and kept in a safe location of your choosing.
|
||||
Naturally, the seriousness of the situation depends on what you're doing with
|
||||
your Kargo cluster, but with these secrets, an attacker will have the ability
|
||||
your Kubespray cluster, but with these secrets, an attacker will have the ability
|
||||
to authenticate to almost everything in Kubernetes and decode all private
|
||||
(HTTPS) traffic on your network signed by Vault certificates.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
- hosts: localhost
|
||||
gather_facts: False
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bastion-ssh-config, tags: ["localhost", "bastion"]}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
# fail. bootstrap-os fixes this on these systems, so in later plays it can be enabled.
|
||||
ansible_ssh_pipelining: false
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bootstrap-os, tags: bootstrap-os}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -34,7 +34,7 @@
|
|||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes/preinstall, tags: preinstall }
|
||||
|
||||
#Handle upgrades to master components first to maintain backwards compat.
|
||||
|
|
@ -42,7 +42,7 @@
|
|||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
serial: 1
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: upgrade/pre-upgrade, tags: pre-upgrade }
|
||||
- { role: kubernetes/node, tags: node }
|
||||
- { role: kubernetes/master, tags: master }
|
||||
|
|
@ -53,8 +53,8 @@
|
|||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
serial: "{{ serial | default('20%') }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: upgrade/pre-upgrade, tags: pre-upgrade }
|
||||
- { role: kubernetes/node, tags: node }
|
||||
- { role: upgrade/post-upgrade, tags: post-upgrade }
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
|
|
|
|||
|
|
@ -14,5 +14,5 @@
|
|||
when: reset_confirmation != "yes"
|
||||
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: reset, tags: reset }
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ spec:
|
|||
labels:
|
||||
k8s-app: dnsmasq
|
||||
kubernetes.io/cluster-service: "true"
|
||||
kargo/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}"
|
||||
kubespray/dnsmasq-checksum: "{{ dnsmasq_stat.stat.checksum }}"
|
||||
spec:
|
||||
containers:
|
||||
- name: dnsmasq
|
||||
|
|
|
|||
|
|
@ -1,5 +0,0 @@
|
|||
- name: Configure defaults
|
||||
debug:
|
||||
msg: "Check roles/kargo-defaults/defaults/main.yml"
|
||||
tags:
|
||||
- always
|
||||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
namespace: {{system_namespace}}
|
||||
labels:
|
||||
k8s-app: kube-apiserver
|
||||
kargo: v2
|
||||
kubespray: v2
|
||||
spec:
|
||||
hostNetwork: true
|
||||
{% if kube_version | version_compare('v1.6', '>=') %}
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
|
||||
# These tasks will undo changes done by kargo in the past if needed (e.g. when upgrading from kargo 2.0.x
|
||||
# These tasks will undo changes done by kubespray in the past if needed (e.g. when upgrading from kubespray 2.0.x
|
||||
# or when changing resolvconf_mode)
|
||||
|
||||
- name: Remove kargo specific config from dhclient config
|
||||
- name: Remove kubespray specific config from dhclient config
|
||||
blockinfile:
|
||||
dest: "{{dhclientconffile}}"
|
||||
state: absent
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
when: dhclientconffile is defined
|
||||
notify: Preinstall | restart network
|
||||
|
||||
- name: Remove kargo specific dhclient hook
|
||||
- name: Remove kubespray specific dhclient hook
|
||||
file:
|
||||
path: "{{ dhclienthookfile }}"
|
||||
state: absent
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
- name: Configure defaults
|
||||
debug:
|
||||
msg: "Check roles/kubespray-defaults/defaults/main.yml"
|
||||
tags:
|
||||
- always
|
||||
|
|
@ -7,7 +7,7 @@
|
|||
vars:
|
||||
ansible_ssh_pipelining: false
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bootstrap-os, tags: bootstrap-os}
|
||||
|
||||
##We still have to gather facts about our masters and etcd nodes
|
||||
|
|
@ -21,7 +21,7 @@
|
|||
- hosts: kube-node
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kernel-upgrade, tags: kernel-upgrade, when: kernel_upgrade is defined and kernel_upgrade }
|
||||
- { role: kubernetes/preinstall, tags: preinstall }
|
||||
- { role: docker, tags: docker }
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
- hosts: localhost
|
||||
gather_facts: False
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bastion-ssh-config, tags: ["localhost", "bastion"]}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
# fail. bootstrap-os fixes this on these systems, so in later plays it can be enabled.
|
||||
ansible_ssh_pipelining: false
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: bootstrap-os, tags: bootstrap-os}
|
||||
|
||||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
- hosts: k8s-cluster:etcd:calico-rr
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kernel-upgrade, tags: kernel-upgrade, when: kernel_upgrade is defined and kernel_upgrade }
|
||||
- { role: kubernetes/preinstall, tags: preinstall }
|
||||
- { role: docker, tags: docker }
|
||||
|
|
@ -36,25 +36,25 @@
|
|||
- hosts: etcd:k8s-cluster:vault
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults, when: "cert_management == 'vault'" }
|
||||
- { role: kubespray-defaults, when: "cert_management == 'vault'" }
|
||||
- { role: vault, tags: vault, vault_bootstrap: true, when: "cert_management == 'vault'" }
|
||||
|
||||
- hosts: etcd
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: etcd, tags: etcd, etcd_cluster_setup: true }
|
||||
|
||||
- hosts: k8s-cluster
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: etcd, tags: etcd, etcd_cluster_setup: false }
|
||||
|
||||
- hosts: etcd:k8s-cluster:vault
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults, when: "cert_management == 'vault'"}
|
||||
- { role: kubespray-defaults, when: "cert_management == 'vault'"}
|
||||
- { role: vault, tags: vault, when: "cert_management == 'vault'"}
|
||||
|
||||
#Handle upgrades to master components first to maintain backwards compat.
|
||||
|
|
@ -62,7 +62,7 @@
|
|||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
serial: 1
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: upgrade/pre-upgrade, tags: pre-upgrade }
|
||||
- { role: kubernetes/node, tags: node }
|
||||
- { role: kubernetes/master, tags: master }
|
||||
|
|
@ -73,35 +73,35 @@
|
|||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
serial: "{{ serial | default('20%') }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: upgrade/pre-upgrade, tags: pre-upgrade }
|
||||
- { role: kubernetes/node, tags: node }
|
||||
- { role: network_plugin, tags: network }
|
||||
- { role: upgrade/post-upgrade, tags: post-upgrade }
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
|
||||
- hosts: kube-master
|
||||
any_errors_fatal: true
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes-apps/network_plugin, tags: network }
|
||||
- { role: kubernetes-apps/policy_controller, tags: policy-controller }
|
||||
|
||||
- hosts: calico-rr
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: network_plugin/calico/rr, tags: network }
|
||||
|
||||
- hosts: k8s-cluster
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: dnsmasq, when: "dns_mode == 'dnsmasq_kubedns'", tags: dnsmasq }
|
||||
- { role: kubernetes/preinstall, when: "dns_mode != 'none' and resolvconf_mode == 'host_resolvconf'", tags: resolvconf }
|
||||
|
||||
- hosts: kube-master[0]
|
||||
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
|
||||
roles:
|
||||
- { role: kargo-defaults}
|
||||
- { role: kubespray-defaults}
|
||||
- { role: kubernetes-apps, tags: apps }
|
||||
|
|
|
|||
Loading…
Reference in New Issue