kubernetes / component-base

Shared code for kubernetes core components

component-base

Purpose

Implement KEP 32: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/783-component-base/README.md

The proposal is essentially about refactoring the Kubernetes core package structure in a way that all core components may share common code around:

• ComponentConfig implementation
• flag and command handling
• HTTPS serving
• delegated authn/z
• logging.

Compatibility

There are NO compatibility guarantees for this repository, yet. It is in direct support of Kubernetes, so branches will track Kubernetes and be compatible with that repo. As we more cleanly separate the layers, we will review the compatibility guarantee. We have a goal to make this easier to use in the future.

Where does it come from?

This repository is synced from https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/component-base. Code changes are made in that location, merged into k8s.io/kubernetes and later synced here.

Things you should NOT do

1. Directly modify any files in this repo. Those are driven from k8s.io/kubernetes/staging/src/k8s.io/component-base.
2. Expect compatibility. This repo is changing quickly in direct support of Kubernetes.

OWNERS

WG Component Standard is working on this refactoring process, which is happening incrementally, starting in the v1.14 cycle. SIG API Machinery and SIG Cluster Lifecycle owns the code.

component-base's Issues

Migrate `component-base` to use Lease API

Support for endpoints and configmaps is removed in K8s 1.24 with kubernetes/kubernetes#106852.
More details about the motivation to switch to leases - ref kubernetes/kubernetes#80289.

To preserve the backwards-compatibility, resource lock for migration purposes (endpointsleases, configmapsleases) should be used when switching from the legacy resource locks (endpoints, configmaps)

component-base is currently using endpoints . We want to migrate this to endpointsleases and finally to leases.

Upgrade go.opentelemetry.io dependencies

The go.opentelemetry.io dependencies are still on some older versions.

The sig-storage upgraded these libs in our csi-lib-utils(kubernetes-csi/csi-lib-utils#140) but the versions are not compatible with what is in the component-base under certain dependency chain.

This causes upgrading dependencies in the csi sidecars failed. For example, the external-provisioner is depending on both csi-lib-utils and component base, in this scenario there is conflict in upgrading.

Similar issue in other repos: open-telemetry/opentelemetry-go#2938
Can component-base update the libs to newer versions?

Information About Issues

From @stealthybox
component-base is an automated staging repository from k/k, so most of the issues end up on kubernetes/kubernetes or their associated component's repo's.
See:

• Project Board
• k/k Issues/PR's needing Review
  The wg label has also been used in other orgs and repos such as kubernetes-sigs/kubebuilder.
  For repos outside of the kubernetes org, I've just been adding links to the respective issues on the Project Board.

build error : cannot use nil as type logr.Logger

when I use this module in my project, go build give me this error:
go version: go 1.17

pkg/mod/k8s.io/[email protected]/logs/config.go:41:22: cannot use nil as type logr.Logger
 in argument to LogRegistry.Register
pkg/mod/k8s.io/[email protected]/logs/registry.go:56:3: cannot use nil as type logr.Logger
 in return argument

Upgrade opentelemetry to new version

There's breaking changes in opentelemetry new version, see https://github.com/open-telemetry/opentelemetry-go/blob/main/CHANGELOG.md

That is to say a project does not work if it depend on this repo and there's also direct/indirect dependencies on the new version of opentelemetry

Upgrade github.com/moby/term to v0.5.0

Upgrade github.com/moby/term to a tagged release: v0.5.0.

$ go get github.com/moby/[email protected] && go mod tidy

Missing kube-api can be configured in the command line

traces utils.go

The most fundamental is that TracingConfiguration does not yet provide a complete configuration

func NewProvider(ctx context.Context, baseSampler sdktrace.Sampler, resourceOpts []resource.Option, opts ...otlpgrpc.Option) trace.TracerProvider {
 opts = append(opts, otlpgrpc.WithInsecure())

 driver := otlpgrpc.NewDriver(opts...)
 exporter, err := otlp.NewExporter(ctx, driver)
 if err != nil {
  klog.Fatalf("Failed to create OTLP exporter: %v", err)
 }

 res, err := resource.New(ctx, resourceOpts...)
 if err != nil {
  klog.Fatalf("Failed to create resource: %v", err)
 }

 // TODO Missing customization
 bsp := sdktrace.NewBatchSpanProcessor(exporter)

 return sdktrace.NewTracerProvider(
  // TODO Missing customization
  sdktrace.WithSampler(sdktrace.ParentBased(baseSampler)),
  sdktrace.WithSpanProcessor(bsp),
  sdktrace.WithResource(res),
 )
}