Image names from 1.16 on include an architecture suffix,
e.g. "-amd64"; the generic alias continues to work when pulling, but
when loading from a tarball (i.e. running in CI) we must use the
per-architecture name.
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.
https://github.com/lyft/cni-ipvlan-vpc-k8s
This cni solution is slightly different in that it doesn't require running a daemonset
It requires:
* a config file in /etc/cni/net.d
* the binaries in /opt/cni/bin
* adding the --node-ip param to the kubelet
This code is modeled after the AmazonVPC cni bits.
I've left the setup of the required subnets as an exercise to the reader.
File assets and the SHA files are uploaded to the new location. Files
when are users uses s3 are upload public read only. The copyfile task
uses only the existing SHA value.
This PR include major refactoring of the use of URLs. Strings are no
longer categnated, but converted into a URL struct and path.Join is
utlilized.
A new values.go file is included so that we can start refactoring more
code out of the "fi" package.
A
- removing the StorageType on the etcd cluster spec (sticking with the Version field only)
- changed the protokube flag back to -etcd-image
- users have to explicitly set the etcd version now; the latest version in gcr.io is 3.0.17
- reverted the ordering on the populate spec
The current implementation is running v2.2.1 which is two year old and end of life. This PR add the ability to use etcd and set the versions if required. Note at the moment the image is still using the gcr.io registry image. As note, much like TLS their presently is not 'automated' migration path from v2 to v3.
- the feature is gated behine the storageType of the etcd cluster, bot clusters events and main must use the same storage type
- the version for v2 is unchanged and pinned at v2.2.1 with v2 using v3.0.17
- @question: we shoudl consider allowing the use to override the images though I think this should be addresses more generically, than one offs here and then. I know chris is working on a asset registry??
fixes#2606
Most part of the changes are similar to current supported CNI networking
provider. Kube-router also support IPVS bassed service proxy which can
be used as replacement for kube-proxy. So the manifest for kube-router
included with this patch enables kube-router to provide pod-to-pod
networking, IPVS based service proxy and ingress pod firewall.
We move everything to the models. We feature-flag it, because we
probably want to change the names etc, and we aren't going to be able to
offer smooth upgrades until that is done.
User reports of kubelet flags not being passed; moved more to code.
Also found & fixed the likely root-cause issue: we have two copies of
the cluster spec and were not being precise about which one we wanted to
use at all times.
* Integrating Canal (Flannel + Calico) for CNI
Initial steps to integrate Canal as a CNI provider for kops
Removed CNI in help as per chrislovecnm
* Integration tests, getting closer to working
- Added some integration tests for Canal
- Finding more places Canal needed to be added
- Sneaking in update to Calico Policy Controller
* Add updated conversion file
* turned back on canal integration tests
* fixed some rebase issues
* Fixed tests and flannel version
* Fixed canal yaml, and some rebasing errors
- Added some env vars to the install-cni container to get the proper
node name handed off
* Added resource limits
- set resource limits on containers for Canal
- Ran through basic calico tutorials to verify functionality
* Updating Calico parts to Calico 2.0.2
Justin SB
mikesplain
Chris Phillips
Maciej Kwiek
Justin Santa Barbara
Tim Hockin
Kubernetes Submit Queue
chrislovecnm
Manuel de Brito Fontes
Caleb Gilmour
Rohith
Murali Reddy
Matthew Mihok
Stephen Schlie