thockin

thockin

Member Since 8 years ago

Google, United States

Experience Points
1.3k
follower
Lessons Completed
0
follow
Lessons Completed
4
stars
Best Reply Awards
53
repos

1006 contributions in the last year

Pinned
⚡ A Makefile/Dockerfile example for Go projects.
⚡ Container Cluster Manager
⚡ My dotfiles
⚡ Kubernetes files for various *.k8s.io sites
Activity
Jan
27
3 hours ago
pull request

thockin merge to kubernetes/utils

thockin
thockin

pointer: Add helper funcs for time.Duration

/kind feature

What this PR does / why we need it: The PR adds helper funcs to the pointer pkg for working with time.Duration.

Release note:

NONE
thockin
thockin

Thanks!

/lgtm /approve

pull request

thockin merge to kubernetes/utils

thockin
thockin

Add IPFamilyOf() / IPFamilyOfString() / IPFamilyOfCIDR() / IPFamilyOfCIDRString()

What type of PR is this? /kind api-change /kind feature

What this PR does / why we need it:

Often you want to test whether two IPs/CIDRs are of the same family,
without actually caring which family they are. While you can do this
by checking:

  if utilsnet.IsIPv6(ip[0]) == utilsnet.IsIPv6(ip[1]) {

this is somewhat confusing to read and can look like it is checking
that they are both IPv6 if you read it quickly.

So add new functions so that you can do

  if utilsnet.IPFamily(ip[0]) == utilsnet.IPFamily(ip[1]) {

(This also renames the former "IPFamily" type to "IPFamilyType", so
that "IPFamily" can be used for a function name.)

Some examples:

Which issue(s) this PR fixes: none

Special notes for your reviewer: I had thought utils wasn't API-stable, but I see in the README.md now that "stable, or backward compatible, API" is listed among the "criteria for adding code here".

I broke API by renaming "IPFamily" to "IPFamilyType" so I could use "IPFamily" as a function name. If I can't do that then I need alternate name suggestions...

Release note:

Renamed the IPFamily type to IPFamilyType.

Added IPFamily() / IPStringFamily() / CIDRFamily() / CIDRStringFamily() functions
to make it easier to check "are these two IPs/CIDRs the same family?"

/sig network /cc @aojea

thockin
thockin

Thanks!

/lgtm /approve

open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

This statement isn't right. You want to clear it IFF the gate is off and it wasn't previously set.

if !utilfeature.DefaultFeatureGate.Enabled(features.PodHostIPs) && !hostIPsInUse(oldPodStatus) {
open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

You don't need to describe the fields of struct you are about to define

open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

you don't need to say "(IPv4 or IPv6)"

open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

a) doesn't seem to be gofmt'ed

b) This is a LOT of whitespace.

Can you instead say:

		return &api.PodStatus{
				HostIPs: []api.HostIP{{
						IP: "10.0.0.1",
					}, {
						IP: "fd00:10::1",
					}},
			}

or even:

		return &api.PodStatus {
			HostIPs: makeHostIPs("10.0.0.1", "fd00:10::1")
		}

with

func makeHostIPs(ips ...string) []api.HostIP {
	ret := []api.HostIP{}
	for _, ip := range ips {
		ret = append(ret, api.HostIP{ IP: ip})
	}
	return ret
}
open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

I'd rename as dropDisabledtStatusFields or just pass staus to the existing function

open pull request

thockin wants to merge kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
thockin
thockin

Can we add the tag so we don't need this?

pull request

thockin merge to kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
pull request

thockin merge to kubernetes/kubernetes

thockin
thockin

[WIP] Field `status.hostIPs` added for Pod

What type of PR is this?

/kind feature /sig node

What this PR does / why we need it:

https://github.com/kubernetes/enhancements/pull/2661 If the Pod runs on an enabled IPv6 dual stack node, hope to get the IPv6 address of node

Which issue(s) this PR fixes:

Fixes #101565 Fixes #85443

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Field status.hostIPs added for Pod
Downward API support for status.hostIPs

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/pull/2661
Jan
26
1 day ago
Activity icon
issue

thockin issue comment kubernetes/kubernetes

thockin
thockin

parse ipv6 address before comparison

Signed-off-by: Jyoti Mahapatra [email protected]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Which issue(s) this PR fixes:

#107735

Fixes #

Special notes for your reviewer:

An issue in aws cloud provider is not sanitizing the imds node ip before being sent to kubelet. As a result, the address provided to the node-ip in kubelet and the one received from cloud provider mismatches.

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


thockin
thockin
open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-3015: PreferLocal traffic policy

  • One-line PR description: Addition of PreferLocal (ie, Local with fallback) to externalTrafficPolicy and internalTrafficPolicy
  • Other comments: based on discussion in #3010, which I'll close now
thockin
thockin

I'll attach my main feedback here.

Let's consider: Why do people use [EI]TP ?

ETP: I know of 2 reasons. 1) "I need to preserve source IP". 2) "Efficiency".

ITP: I know of 2 reasons. 1) "I need to stay on this node (semantic correctness)". 2) "Efficiency".

For both classes of traffic, "Local" is either a hard requirement (i.e. "prefer" is a non-starter) or just an optimization over "Cluster".

I don't like that we put the responsibility onto our users tell us which optimizations we should be using. That seems like a total failure on our part. OF COURSE they want us to optimize if we can. The specific optimization that PreferLocal dictates is pretty black or white, which means there's not much room for being "smart". This then FORCES other implementations, which might be capable of more smartness, to play dumb.

For example, it's really not hard to imagine an implementation that sends the number of active flows per-endpoint to an aggregator, and then have that aggregator give the node-agents hints about which endpoints are overloaded. It doesn't even need to be super timely to have some impact, I bet. But the semantics of "PreferLocal" disallow that.

If we think this is the optimizatrion with the biggest bang for the buck, let's talk about how we can do something like if num_endpoints > (num_nodes/2) && have_local_eps() { use_local_eps() }. I just made that up - obviously we can tune the heuristic.

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-3015: PreferLocal traffic policy

  • One-line PR description: Addition of PreferLocal (ie, Local with fallback) to externalTrafficPolicy and internalTrafficPolicy
  • Other comments: based on discussion in #3010, which I'll close now
thockin
thockin

Overall I am -1 on this proposal. Rationale in a line-comment below.

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-3015: PreferLocal traffic policy

  • One-line PR description: Addition of PreferLocal (ie, Local with fallback) to externalTrafficPolicy and internalTrafficPolicy
  • Other comments: based on discussion in #3010, which I'll close now
thockin
thockin

Overall I am -1 on this proposal. Rationale in a line-comment below.

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

add non-graceful node shutdown KEP

Signed-off-by: Yassine TIJANI [email protected]

Opening a PR for a first round of reviews, documented other alternatives and how to handle version skew.

/assign @smarterclayton @liggitt @yujuhong @saad-ali /cc @jingxu97 @derekwaynecarr @andrewsykim

/sig node /sig cloud-provider /sig storage /sig scalability

thockin
thockin

...unless I amissing something?

It seems overll simpler to say:

  • taints work as normal
  • if a pod has a deletionTimestamp and the node is out-of-service, it's OK to force delete
  • if a VolumeAttachment points to a node that is out-of-service and no running pods use it, it's OK to force detach
pull request

thockin merge to kubernetes/enhancements

thockin
thockin

add non-graceful node shutdown KEP

Signed-off-by: Yassine TIJANI [email protected]

Opening a PR for a first round of reviews, documented other alternatives and how to handle version skew.

/assign @smarterclayton @liggitt @yujuhong @saad-ali /cc @jingxu97 @derekwaynecarr @andrewsykim

/sig node /sig cloud-provider /sig storage /sig scalability

Activity icon
issue

thockin issue comment kubernetes/enhancements

thockin
thockin

KEP-2819: CNI traffic shaping support

  • One-line PR description: revive old KEP
  • Other comments:

Note: This is not a new KEP. It is for regain tracking of an already-implemented feature (in alpha)

This KEP is revived to regain tracking for the traffic shaping feature. It was introduced in v1.9 (I think) but has not left "alpha" since 2018. The intention is to allow the function to graduate. (https://github.com/kubernetes/community/pull/2202#issuecomment-873306405)

The original KEP was not merged or moved to kubernetes/enhancements.

Links

thockin
thockin

For email's sake - sorry, I missed your reply.

On Wed, Jan 26, 2022 at 1:35 PM Tim Hockin ***@wrote:

ping @uablrek https://github.com/uablrek - 1.24 deadline looming :)

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/enhancements/pull/2808#issuecomment-1022624001, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVCI3CCJY75H6B4YXWTUYBSINANCNFSM47YETHGA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

Activity icon
issue

thockin issue comment kubernetes/enhancements

thockin
thockin

KEP-1669: updates for ProxyTerminatingEndpoints feature in v1.24

Signed-off-by: Andrew Sy Kim [email protected]

  • One-line PR description: v1.24 updates for KEP-1669.
  • Other comments:

After some thought, I decided to consolidate handling both external/internal traffic under a single feature. I think overall this is simpler. The implication for v1.24 though is that the feature will remain alpha since we haven't actually implemented the feature at all for internal traffic yet and we probably want that for at least 1 release before thinking about the promotion to beta.

thockin
thockin

I take no real opinion on whether one should use Cluster or Local for this sort of setting, but both are valid.

If PTE-Cluster is net simpler to document and explain ("we always use ready endpoints unless none exist, in which case we use terminating endpoints if they are still serving" vs all sorts of conditional clauses around policy) and the only real difference is when we switch from using terminating endpoints to blackholes, is that justifiable?

NOTE: I haven't tried to look a t the code for this, but I can't see how less special-cases won't be better.

On Wed, Jan 26, 2022 at 1:36 PM Antonio Ojea ***@wrote:

The difference is in t4-t5

Is that at all convincing? :)

why should you use Cluster for that when we have a canonical way of using LB for these setups with Local?

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/enhancements/pull/3174#issuecomment-1022624819, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVHVBXNSSKJJF5TG6KLUYBSMHANCNFSM5MQASHBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were assigned.Message ID: @.***>

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

I don't like "should" here. It's pointless. How will this be used? I assume it will be primarily interpreted by implementations of things like MCS and maybe compared(opaquely) between clusters, but not interpreted by arbitrary clients?

As such, I don't think we need to spec anything about character set. Implementations will take "should" as advisory or they will end up doing pointless transformations.

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

s/ **may not** exist/**need not** exist/ ? Or something. As written I see "it is not allowed to exist".

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

Why is this linked to ClusterSet at all? Can't I have this for standaalone clusters?

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

I asked somewhere (can't find where) about whether we can/should revisit the need for suffix for "well known" properties vs user-defined. I.e could/should these be "id", "network", "clusterset" ?

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

I think I'm fine with this, overall. I know this is modelled in some other systems (e.g. Istio) so maybe we shoudl solicit input on its utilty for them?

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

I think I'm fine with this, overall. I know this is modelled in some other systems (e.g. Istio) so maybe we shoudl solicit input on its utilty for them?

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

multi-net exists in the form of multus and there have been some new mumbles about making it more first-class. I think it's probably safe to assume that there's a "default' network or "pod network", and this property models that?

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

pull request

thockin merge to kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

open pull request

thockin wants to merge kubernetes/enhancements

thockin
thockin

KEP-1645: Add spec for multi-network scenario

  • Add the necessary changes to support MCS spec for multi-network scenario.

Refer to this draft for more details.

thockin
thockin

I don't think there's actually a KEP for "weight" in EndpointSlices, is there? @robscott @JeremyOT @lauralorenz @bowei

Given the KEP freeze next week, there's still time, but not very much, for v1.24, if someone jumps on this. Otherwise the earliest possible alpha is 1.25 (summer)

Activity icon
issue

thockin issue comment kubernetes/enhancements

thockin
thockin

KEP-3037: client-go alternative services

  • One-line PR description: client-go capability to connect to multiple apiservers
thockin
thockin

I think multiple IPs in client-go is a relatively obvious thing to do.

I don't find alt-svc to be bad, just very very niche. I don't feel like my opinion (with sig-net hat on) should be on the same tier with @lavalamp though, since he is much more in tune with api-machinery.

Activity icon
issue

thockin issue comment kubernetes/enhancements

thockin
thockin

KEP-2839: Add KEP for in-use protection

  • One-line PR description: A generic feature to protect objects from deletion while it is in use
  • Other comments:
thockin
thockin

Ping? KEP freeze is looming

Previous