* use Knative certificates for Serving encryption
* Make namespace the owner of the Queue-Proxy certificate
* Lint error fixes
* Minor fixes
* cherry-pick https://github.com/knative/serving/pull/14706
* keep existing secret in upgrade/downgrade tests
* Rebase and update to upstream/main
* Review improvements
* Update net-istio
* Use a revision tracker to reconcile on KCerts
* Fix: Raise the reconciliation timeout from 10 to 30s.
This was actually something I had asked for a fairly long time ago, which I had wanted to move into `genreconciler` to encourage folks to move "long" work off of the main reconciliation thread. `10s` was sort of pulled out of thin air, and seemed like a good idea at the time! However, this arbitrary choice has come back to bite me!
Investigating a rash of timeouts in the sigstore policy-controller webhook, I noticed that a great deal of requests were timing out at `10s` despite the webhook having a `25s` `timeoutSeconds`.
Breaking this down by resource kind, I found that the only resources timing out at `9-10s` were ALL deployments, where replicasets and pods had some timeouts, but almost all were at the `25s` mark.
So basically when Knative reconciles Deployments, it is setting a `10s` deadline on its outbound API requests, including Deployment updates, which pass this deadline on to downstream requests such as webhooks.
My reasoning for advocating for `30s` is not arbitrary, it is based on this being the maximum value that a webhook can have for its `timeoutSeconds` field:
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#timeouts
This means that Knative wouldn't be artificially lowering the webhook timeout on any webhooks configured on the resources it is managing directly.
* Use the global variable
* Add flag for timeout
* Add certificate reconciler for internal certs
* Fix cert path
* Temporary use local networking repo
* Support internal-encryption configuration
* Use const for cert name
* Fix lint
* rm blank line
* Drop unused variable
* Use one line style
* Use one line code
* Update net-kourier nightly
bumping knative.dev/net-kourier d758682...b9b1e8b:
> b9b1e8b Use `internal-encryption` to deploy internal certificates automatically (# 855)
> 427434c bump kind and k8s versions in kind-e2e tests (# 859)
Signed-off-by: Knative Automation <automation@knative.team>
* Verify SecretPKKey as well
* Do not drop activator always in the path
* Comment about ctrl-ca suffix
Co-authored-by: Knative Automation <automation@knative.team>
* Consolidate serving-nscert controller into main controller.
* Fix up e2e tests
* Remove wildcard cert stuff from generate-yamls and install.
* Fix lint.
* Address nak3 feedback; remove a no-longer-needed utility program
* Clean up the rest of SERVING_NSCERT_YAML (which was an empty file).
* Remove the rest of SERVING_NSCERT_YAML
* Enable HA by default
* Centralize the bucket/replica information for running the HA testing.
Add a test to ensure the count of the controller's reconciler stays in sync with the actual controller binary.
* Hook up Certificate and ClusterIngressTLS into Route controller
* add unit tests
* fix failed e2e test
* use autoTLS feature flag to control autoTLS
* Update pkg/reconciler/route/resources/names/names.go
Co-Authored-By: ZhiminXiang <zhiminx@google.com>
* fix typo
* fix unit test
* remove certificates from routestatus
* only consider non-wildcard in the code
* fix unit test
* fix typos
* copy secret per ClusterIngress
* address comment
* mark URLs to HTTPS when certificate is ready
* address comment
We had done this with an ignorance of how CRD versioning would work. We now know this to be unnecessary and it's more typing.
This change is the result of the following commands:
```
sed -i 's@pkg/reconciler/v1alpha1@pkg/reconciler@g' $(find -name '*.go' | xargs grep 'pkg/reconciler/v1alpha1' | cut -d':' -f 1 | uniq)
git mv pkg/reconciler/v1alpha1/* pkg/reconciler/
for x in $(find pkg/reconciler -name '*.yaml'); do rm $x; ln -s -r config/$(basename $x) $x; done
```
I've also edited the paths in `hack/update-codegen.sh`.
* This implements "BYO Revision name".
With this change, in any context where a user might specify a
`RevisionTemplateSpec`, they may now provide their own Revision name:
```yaml
kind: Configuration
metadata:
name: config
spec:
revisionTemplate:
metadata:
name: config-foo # Must have config- prefix.
spec:
...
```
The intent of this is to enable GitOps scenarios which cannot be covered
well by our generated names today. With this in the context of Service,
a new Revision may be staged via something like:
```yaml
kind: Service
metadata:
name: svc
spec:
release:
revisions: [svc-2019-03-27, svc-2019-03-28]
percent: 1
metadata:
name: svc-2019-03-28
spec:
...
```
In the above example, once `svc-2019-03-28` is `Ready` it will
automatically begin receiving 1% of traffic.
The restrictions on BYO name are as follows:
* The name must change (or be removed) any time the body of the
`revisionTemplate` changes.
* The name must be prefixed by the name of the enclosing Service
or Configuration with a trailing `-`.
* The name must be unique across the namespace (the above is intended
to help with this, and preserve some of the self-documenting nature
of the prefix, but it doesn't guarantee collision avoidance).
* Relax the collision validation to allow spec equivalence.
This change is inspired by a use case that arose in a slack
conversation around `git revert` with GitOps.
The example is the following is committed:
```yaml
spec:
template:
metadata:
name: mattmoor-foo
spec:
A
```
Then the following update is committed:
```yaml
spec:
template:
metadata:
name: mattmoor-bar
spec:
B
```
Then a problem is discovered with the above and a `git revert`
is done to the prior state:
```yaml
spec:
template:
metadata:
name: mattmoor-foo
spec:
A
```
In the original model, this case would be rejected by the Service
controller due to the generation mismatch between the existing
`mattmoor-foo` and the latest generation of the underlying
Configuration.
* Move away from abusing apis.Immutable for BYO name validation.
This replaces the current abuse to `apis.Immutable` for checking
certain properties of BYO Revision name in the webhook. It replaces
them with the context-based approach we are moving towards to more
holistically replace `apis.Immutable` with `apis.Validate`.
* Incorporate review feedback from @vagababov
Fix some lint issues.
Moves to the shared context stuff in knative/pkg
Fix cmp.Diff orientation.
* Disallow BYO name in conjunction with generateName in the parent.
* Conflicting revision names should be fatal.
* SafeDiff to ShortDiff
In order to allow pluggable clusteringress we run our (istio) cotroller
separately as a user may prefer to only run a different controller.
Related-to: #2322
* New Serverless Service Controller initial impl
* remove the metrics port as discussed
* proper schema registration
* group change re-done
* Negative table tests. Some
* add more tests
* final coverage
* address the comments
* initial version of reconciling Istio Gateway for ClusterIngressTLS
* fix lint
* a part of unit test fix
* fix the unit test
* fix typo
* address comments
* fix typos
* address comment
* add more test case
* use only one gateway in the test because the order of two gateways is uncertain, which causes unit test flaky
* remove mutex from clusteringress and use optimistic concurrency strategy
* refactor the reconcileGateways for future reuse
* User can specify the namespace in yaml for knative-serving
* use getter method for namespaces
* add default namespaces for test
* panic if the SYSTEM_NAMESPACE environment variable isn't set
This makes `pkg/system` panic if `SYSTEM_NAMESPACE` is not set. For tests, it exposes a simple library you can link to set this variable to a suitable namespace.
* update namespace in crd_checks.go
* change test ns knative-serving to knative-testing
* use environment value set the autoscaler namespaces
* queue get env from system.Namespace
* update the test case to match the new environment value
* Clean up logging in controller main files
There is a lot of inconsistent use of the Zap logging functionality
throughout the project. This change moves all of the controller main
functions to use the Zap With() syntax when errors are present. This
fixes a bug in output for logging calls that forgot the "w" at the end of
the logging output level, and changes sprintf formatted error messages
to the use context options of Zap.
This change targets just these files to limit conflicts generated by a
larger single commit.
Previous log line without "w" or "f":
{"level":"info","msg":"Previous message.{error 25 0 Example Error}"}
Previous log line with "f":
{"level":"info","msg":"Previous message: Example Error"}
New log line with "w":
{"level":"info","msg":"New Message","error":"Example Error"}
* Update cmd/autoscaler/main.go
* Update cmd/controller/main.go
* Update test/controller/main.go
This draws inspiration largely from https://github.com/knative/pkg/pull/173, which prompted me to measure and investigate. You can see some more detailed timings in that thread.
As we've grown the number of reconciler processes in our controller image, the QPS limits with which we talk to the API server have remained the same. The meant that it took ~3 min to deploy 50 services, and ~6 min to deploy 100.
This change simply bumps those limits to `{number of reconciler processes} x {default value}` to approximate the limits we'd have if we ran each controller process as a separate Pod.
After applying this change we see a ~60% improvement, it takes ~70 seconds to deploy 50 services, and ~2:30 min to deploy 100.
> Note that it is unlikely that this same improvement will apply to less bursty deployments, but the improvement is substantial for bursty deployments.
* introduce a lib in pkg to read file from kodata and use it to read commit id and tag it to logs label
* introudce a lib called changeset instead of ko
* nits fix
* update knative/pkg
* remove serving/pkg/changeset
* rerun update-deps
* Disable labeling.
This is a precursor to moving this into a separate reconciliation process.
* Add a "labeler" Reconciler.
This Reconciler is responsible for applying Route labels to Configuration.
Fixes: https://github.com/knative/serving/issues/1129
* Incorporate review feedback from nghia and vincent.
This removes the VPA integration from the Revision controller to simplify things.
In the KPA architecture, the VPA doesn't belong here anyways, and before it is added back I'd like e2e tests making sure it actually WAI so that changes don't break it or the code will just rot.
Fixes: https://github.com/knative/serving/issues/1876