Giter VIP home page Giter VIP logo

bootkube-ci's Introduction

Bootkube-CI is a simple Kubernetes environment that can be used for a number of CI, development and/or demonstration scenarios. A primary usecase for this repository is for the demonstration of OpenStack-Helm delivered on top of a Self-Hosted Kubernetes control plane via Kubernetes-Incubator/Bootkube.

Deployment Instructions:

If you wish to use this repository for CI or for bringing up a Kubernetes cluster, simply clone and edit the .bootkube_env file to match your environment. Currently, two SDN's are optional and included (Calico is default).

Included with this repository are the concepts of "add-ons": other deployment scenarios that you may want to run after a Kubernetes self-hosted cluster has been deployed. Using these are just as straight-forward as using the deployment itself. So if you wanted to deploy openstack-helm for example, all that would be required is the following:

git clone https://github.com/v1k0d3n/bootkube-ci.git

## make any variable modifications via your CI platform of choice to both .bootkube-env and ./deploy-addons/openstack-helm-up.sh
## and deploy

cd bootkube-ci
./bootkube-up
cd deploy-addons
./openstack-helm-up

# done

Kubernetes Config File

By default, the Bootkube generated Kubernetes configuration will not work with Armada, because the config is not technically valid (Tiller will return an error message). This is because the certificate and key data is REDACTED, and because there is no default context configured. In order to create a valid /home/${USER}/.kube/config file (for use with Armada), you will need to perform the following manual actions:

### Move Old Kubernetes Config:
#   Source .bootkube_env file in bootkube-ci folder:
source .bootkube_env
sudo mv ${HOME}/.kube/config ${HOME}/

### Create Valid Kubernetes User Config:
sudo kubectl config set-cluster local --server=https://${KUBE_MASTER}:${KUBE_SVC_PORT} --certificate-authority=${BOOTKUBE_DIR}/.bootkube/tls/ca.crt
sudo kubectl config set-context default --cluster=local --user=kubelet
sudo kubectl config use-context default
sudo kubectl config set-credentials kubelet --client-certificate=${BOOTKUBE_DIR}/.bootkube/tls/kubelet.crt  --client-key=${BOOTKUBE_DIR}/.bootkube/tls/kubelet.key
sudo chown -R ${USER} ${HOME}/.kube

Now you should be able to use your cluster with Armada.

Creating Client Certificates

Currently, this project uses the kubelet user for communicating with the cluster. In production environments, this is unacceptable. You will want to consider creating authenticated client certificates so your users can communicate with the cluster with valid certificates and RBAC policies. To create client certificates, perform the following additional tasks (we will make this default behavior soon):

### EXPORT ORG NAME/EXPIRATION IN DAYS:
export ORGANIZATION=charter
export CERT_EXPIRATION=730

### DIRECTORY PREPARATION:
mkdir -f ~/.kube_certs
mv ~/.kube/config ~/.kube/backup_kubeconfig
rm -rf ${HOME}/.kube_certs/*

### CERTIFICATE CREATION FOR END USERS:
openssl genrsa -out ~/.kube_certs/${USER}.key 2048
openssl req -new -key ~/.kube_certs/${USER}.key -out ~/.kube_certs/${USER}.csr -subj "/CN=${USER}/O=${ORGANIZATION}"
openssl x509 -req -in ~/.kube_certs/${USER}.csr -CA ~/.bootkube/tls/ca.crt -CAkey ~/.bootkube/tls/ca.key -CAcreateserial -out ~/.kube_certs/${USER}.crt -days ${CERT_EXPIRATION}

Resizing Etcd Cluster:

Bootkube leverages an Etcd Operator provided by CoreOS. This means that Etcd can be dynamically scaled and various maintenance functions can be performed as well. To scale your Etcd cluster, you'll want to adjust the size definition located within the spec section of the deployed Custom Resource (CRD). To obtain the CRD, export it and modify the size to the desired number of Etcd members.

# export the crd:
kubectl get EtcdCluster -n kube-system -o yaml > ${HOME}/bootkube-ci/etcd-cluster-resize.yaml

# example spec section below:
  spec:
    TLS:
      static:
        member:
          peerSecret: etcd-peer-tls
          serverSecret: etcd-server-tls
        operatorSecret: etcd-client-tls
    baseImage: quay.io/coreos/etcd
    pod:
      nodeSelector:
        node-role.kubernetes.io/master: ""
      resources: {}
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    selfHosted:
      bootMemberClientEndpoint: https://10.96.0.20:12379
    size: 1 ## << EDIT TO "size: 5"
    version: 3.1.8
    
# save and apply:
sudo kubectl apply -f ${HOME}/bootkube-ci/etcd-cluster-resize.yaml

Default Behavior

The default behavior for this small project is to deploy the following:

  • Kubernetes v1.7.5
  • Ceph is available as part of deploy-addons/openstack-helm-up (look for and source the .osh_env file in that directory)
  • AIO and Multi-node self-hosted Kubernetes cluster using Bootkube
  • Deploy Calico or Canal CNI/SDN with etcd for the Calico Policy Controller (POD_CIDR='10.25.0.0/16' and SVC_CIDR='10.96.0.0/16')
  • Kubernetes API endpoint can be discovered locally at https://kubernetes.default:8443

Calico L3

For Calico to work correctly, you will need to change the following flags in the bootkube-up.sh script:

export NSERVER01='10.96.0.10'               ### MODIFY FOR CEPH PVC         ###
export KUBE_SDN='calico'                    ### SDN SELECTION               ###
export KUBE_POD_CIDR='10.25.0.0/16'         ### SDN POD CIDR RANGE          ###
export KUBE_SVC_CIDR='10.96.0.0/16'         ### SDN SERVICE CIDR RANGE      ###
export KUBE_DNS_API='kubernetes.default'    ### DNS API ENDPOINT            ###

Canal L2

For Canal to work correctly, change these flags to the following:

export NSERVER01='10.3.0.10'                ### MODIFY FOR CEPH PVC         ###
export KUBE_SDN='canal'                     ### SDN SELECTION               ###
export KUBE_POD_CIDR='10.2.0.0/16'          ### SDN POD CIDR RANGE          ###
export KUBE_SVC_CIDR='10.3.0.0/24'          ### SDN SERVICE CIDR RANGE      ###
export KUBE_DNS_API='kubernetes'            ### DNS API ENDPOINT            ###

Additional Custom Options:

Two areas should be considered for customizing the Bootkube-CI deployment. The first area that may need modified are the variables at the top of the bootkube-up.sh script. The second place you may want to consider is related to the deployed SDN manifests in the deploy-sdn folder. Feel free to submit an issue, or contact me on Kubernetes Slack (v1k0d3n).

Adding additional Architectures:

Both amd64 and arm64 are currently supported. Please refer to the .bootkube_env file.

TODO:

This repo is in heavy development at this time. It is understood that several improvements can be made. If you have any feature requests or comments, please feel free to submit a pull request of create an issue.

bootkube-ci's People

Contributors

blsaws avatar braynshock avatar bzub avatar larryrensing avatar v1k0d3n avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

bootkube-ci's Issues

kube-router SDN not working

Bringing the discussion from #3 to a proper issue.

The error with seen with kube-router is:

ubuntu@osh-sh-ci-01:~$ kubectl logs  kube-router-hkf2d -n kube-system
panic: nodes "kubernetes" not found

goroutine 1 [running]:
panic(0x1596120, 0xc42040a450)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/cloudnativelabs/kube-router/app/controllers.NewNetworkPolicyController(0xc420315540, 0xc420314960, 0x0, 0x0, 0x0)
	/home/kube/go/src/github.com/cloudnativelabs/kube-router/app/controllers/network_policy_controller.go:785 +0x413
github.com/cloudnativelabs/kube-router/app.(*KubeRouter).Run(0xc4203c1660, 0xc4203c1660, 0x0)
	/home/kube/go/src/github.com/cloudnativelabs/kube-router/app/server.go:120 +0x710
main.main()
	/home/kube/go/src/github.com/cloudnativelabs/kube-router/kube-router.go:37 +0x13c
ubuntu@osh-sh-ci-01:~$ 

random issues to consider

@v1k0d3n , Just wanted to mention these...

  1. Not sure which combination of packages. But i've had issues with sudo after installing ZFS then running bootkube (i think it's the docker package that is causing it).... Sudo fails, long story short it's an issue with /dev/null permissions, and some package adding a configuration line to /etc/sudoers to log to /dev/null... manually edited to remove, and it works again.

  2. Another issue I was having was with having to manually add kubernetes.default to my /etc/hosts file. After doing that twice, i realized i could have just edited .bootkube.env to be my server's hostname. (User error)
    **This issue was causing my containers to come up without IP addresses... and the api-server to crash constantly.

  3. DNSmasq was also causing random crashing issues for the containers, so I manually disabled DNSmasq and fixed /etc/resolv.conf.

  4. In addition, I don't think bootkube-clean.sh is putting it back the way it was before bootkube-up.sh...

Anyway, hope these help someone else.

I now have a clean metal install, with a ZFS storage array, just need to figure out how to point etcd to use it.

docker api version mismatch

found out that the api version for docker 17.06+ will not exactly work with the openstack-helm deployments, and thus i need to fall back to installing via the standard ubuntu packages (docker.io).

i need to fix this tonight.

static directories for consistency

for a while it was perfectly fine to have users download bootkube-ci to whatever directory they want, but i think going forward it would make sense to force some directories in order to provide better consistency/reliability for the project.

/opt/bootkube should be used, and docs will need to be updated to reflect this. /etc/bootkube can be used for some of the deployment yaml's (coming soon), which are simply exported variable files at this point. once we move to systemd units, we can create a systemd EnvironmentFile.

Fails with kubectl not found

Ran through the setup, but it failed very early on:

./bootkube-ci/bootkube-up.sh: line 199: grep: command not found
./bootkube-ci/bootkube-up.sh: line 199: grep: command not found
^C

Looks like kubectl not found by the script:

rwellum@bootkube-ci:~$ kubectl
kubectl: command not found

What's also odd is this left my ubuntu VM in a very odd state - for example can't find basic commands like 'which' and 'grep' - but they are installed of course. So I think my VM is smoked.

ceph-common version upgrade?

Hi! I also like to bundle ceph-common into hyperkube, and I had some issues with PVCs getting stuck trying to be mapped to my nodes. I updated ceph-common to the official Ceph Kraken packages and those issues seemed to go away, although I cannot confirm the root cause of the issue.

Anyways, if you're interested in using ceph tools for a recent Ceph release in hyperkube, here's how I did it in the Dockerfile:

before:

# [...]
RUN DEBIAN_FRONTEND=noninteractive apt-get update -y \
    && DEBIAN_FRONTEND=noninteractive apt-get -yy -q install \
    iptables \
    # [...]

after:

# [...]
RUN apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 08b73419ac32b4e966c1a330e84ac2c0460f3994 \
    && echo "deb http://download.ceph.com/debian-kraken/ jessie main" > /etc/apt/sources.list.d/ceph-kraken.list \
    && DEBIAN_FRONTEND=noninteractive apt-get update -y \
    && DEBIAN_FRONTEND=noninteractive apt-get -yy -q install \
    iptables \
    # [...]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.