Two feature gate constants were missing the explicit `featuregate.Feature`
type annotation, making them inconsistent with the rest of the file:
- ChangeContainerStatusOnKubeletRestart
- StatefulSetSemanticRevisionComparison
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Replace the context.TODO with getContext to prefer the Helper's context
when it is set. This is consistent with the rest of the package now.
Since contextual logging or timeouts may be included as part of the
Helper's context, using context.TODO will silently ignore these
features, producing unexpected behaviors.
Signed-off-by: Kirsten Laskoski <klaskosk@redhat.com>
Currently, we set TLSConfig.Config.GetCertificate, but then also pass
certificate and key paths to http.Server.ListenAndServeTLS.
ListenAndServeTLS uses these paths to populate the TLS config Certificate
property. Then, when accepting connections, a non-nil Certificate is preferred
over GetCertificate if the ServerName is not set in ClientHelloInfo. Finally,
the Go TLS client doesn't set ServerName when connecting by IP. As a result,
when connecting to the kubelet by IP (e.g. to fetch pod logs), stale
certificates are served.
This patch passes empty certFile and keyFile arguments, to force the TLS
server to use the GetCertificate function.
This is done by clearing key/cert file config when setting GetCertificate as
suggested in PR review. This way, all downstream users of kubeDeps.TLSConfig
will do the right thing automatically.
The client-go feature gates implementation logs information about feature
states at V(1). Changing that would imply changing the Enabled method, which is
very intrusive because there are many callers which are not expected to log and
thus don't have access to a contextual logger.
The code is not active in Kubernetes components, those use the clientAdapter to
make client-go use the normal feature gate implementation, which doesn't log
anything. Therefore the code doesn't get changed and only annotated so that
logcheck won't complain.
The only log output is for error messages which should normally not occur. It's
also likely that users expect to see exactly those messages, so it's better to
not touch them.
When debugging, it helps to keep output from different connections
separate. This can be done with contextual logging and using different loggers
for each connection.
Cancellation is handled separately for requests. Therefore the new APIs only
add support for passing a logger instance.
The main purpose is to replace context.TODO with a context provided by the
caller. A secondary purpose is to enable contextual logging.
Modifying the existing interfaces and APIs would have a big impact on the
ecosystem. This is a no-go. Instead, the following approach was taken:
- All interfaces get duplicated in a *WithContext variant where the methods
also have a *WithContext suffix and the ctx parameter. All methods are
treated this way except for obvious local get methods (like RESTClient)
because it cannot be ruled out entirely that some implementation may
need a context.
- Implementations of these interfaces implement both method variants
which is possible because the method names are different.
The old methods are implemented as thin wrappers around the updated
code which is now the body of the new methods or shared helpers.
In some cases there is additional overhead (type checks, potentially
additional allocations) when using the old methods.
- To*WithContext helpers bridge from the old to the new interfaces. They
try a type cast first. Because the in-tree implementations implement
both, they can be used directly. For other implementations wrappers
are used.
- All old APIs and interfaces are marked as deprecated. There is no
intent to ever remove them, but consumers should be made aware
that there are now better alternatives. Implementations also
get marked this way even if nothing ever calls them directly
because it shows which code, at least theoretically, could get
removed.
- Existing unit tests do not get updated to the new APIs. This gives
us unit test coverage of the old and new API because the old
APIs call the new ones.
- In-tree consumers will be updated in follow-up PRs. This is likely
to be a longer process. Because of the deprecation comment,
`hack/golangci-lint.sh -n` can be used to find code which needs
to be updated.
I wasn't entirely sure whether this should return a value or a pointer to
satisfy the interface. Both works, so I benchmarked it elsewhere (REST
mapper). Mem allocs are the same (one alloc/call), but returning a value is 10%
slower when calling one method.
What I then benchmarked is whether pointer vs value receiver in the wrapper
makes a difference. Converting from value receiver (what I had before) to
pointer receiver reduced call overhead by 6%. That's because with a value
receiver, Go has to auto-generate a variant with pointer receiver and calls the
value receiver through that.
That can be seen in a debugger (call stack) and when setting breakpoints:
(dlv) b restMapperWrapper.KindForWithContext
Command failed: Location "restMapperWrapper.KindForWithContext" ambiguous: k8s.io/apimachinery/pkg/api/meta.restMapperWrapper.KindForWithContext, k8s.io/apimachinery/pkg/api/meta.(*restMapperWrapper).KindForWithContext…
Conventional wisdom is to define types with value receiver because those can be
called also on unmutable instances, making them more flexible.
But for types which will only ever be used via a pointer, I think pointer
receiver is better for the reasons above (small performance difference, easier
to debug).
The allowRelaxedServiceNameValidation() function currently only checks
service names in spec.rules, but it should also check the service name
in spec.defaultBackend.
When an Ingress has a defaultBackend with a service name that is valid
per RFC 1123 but invalid per RFC 1035 (e.g., starting with a digit like
"1-default-service"), the function incorrectly returns false. This
prevents users from updating such Ingresses even though they were
validly created in the past.
This commit adds validation for spec.defaultBackend.service.name to
maintain backward compatibility for existing Ingresses.
If the user has provided extraArgs with an order that has
significance (e.g. --service-account-issuer for kube-apiserver),
kubeadm will correctly override any base args, but will end up
sorting the entire resulting list, which is not desired.
Instead, only sort the base arguments and preserve the order
of overrides provided by the user.
Add counter metric to track pods that schedule immediately after
being flushed from unschedulablePods due to timeout. Uses a boolean
flag that is cleared when pods return to queue or move via events.
This metric tracks pods that successfully schedule after being
flushed from unschedulablePods due to timeout. High values may
indicate missing queue hint optimizations or event handling issues.
with the current established limits we can see the following error:
```
failed to list <object>: unable to determine group/version/kind: cbor:
exceeded max number of elements 1024 for CBOR array.
```
This test verifies that when a job with PodReplacementPolicy=Failed is
suspended and pods are terminating, resource updates can be made to the
job but new pods are only created after terminating pods are removed.
The new pods should have the updated resources.
